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Table 1: STATE DIAGRAM MEALY MACHINE SPECIFICATION KEYWORDS in YEROTH_QVGE 


scientific keywords engineering keywords 


in_set_trace in_sql_event_log 


not_in_set_trace not_in_sql_event_log 


recovery_sql_query | recovery_sql_query 
STATE STATE 

START_STATE BEGIN_STATE 
FINAL_STATE END_STATE / ERROR_STATE 


IN_PRE IN_BEFORE 


IN_POST IN_AFTER 
NOT_IN_PRE NOT_IN_ BEFORE 
NOT_IN_POST NOT_IN_AFTER 


Figure 2: A motivating example, as previous bug found in YEROTH—ERP-3.0. 
Q0 := NOT_IN_BEFORE(YR_ASSET, department.department_name). 


QI :=IN_AFTER(YR_ASSET, stocks.department_name). 


D [in_sql_event_log(’DELETE.department.YR_ASSET’, STATE(D))] /"SELECT.department’ 
start 
Qo 


Figure 3: ASAMPLE state diagram mealy machine file. 


1. yr_sd_mealy_automaton_spec yr_missing_department_NO_DELETE 

23: 

Su START_STATE (d) :NOT_IN_BEFORE (YR_ASSET, department .department_name) 

4. —>[in_sql_event_log(’ DELETE.departement.YR_ASSET’,STATE(d))]/’ SELECT.department’ —> 

5s ERROR_STATE (e) : IN_AFTER(YR_ASSET, stocks.department_name) . 

6. } 

Figure 5: ASCREENSHOT OF yr-pDB-RUNTIME-VERIF 
Figure 4: ASCREENSHOT OF YEROTH_QVGE. SQL EVENT LOG. 
Ihomeyer/Downkoads/VRiimagesiye..s4_ runtime. verit language. EXAMPLE. xgr - YR-Gt Visual Graph Editor 0.YR,0 (64bit} So. YR-DB-RUNTIME-VERIF _ console meh es 

File Eat Select View Grapnviz Window Help 

ca & *&e HH O BR RF ; BH FF e@e@QqQqgaé@ a @ 


New Gpen Save Unio Cut Copy Paste Delete Find  Selectitems CreateNodes Transform Factor Zoom 163% Unzoom Fitto View Fit Selection 


Custom Attributes: 0 


Edges: 
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1. Introduction 


Figure 6: SOFTWARE ARCHITECTURE OF YR-DB- 
RUNTIME-VERIF. 


QT socket calls (via Qt—Dbus) 
SUT source code instrumented t t 
MYSQL library methods calls ain t 


OS system calls tt t 


This user's guide helps briefly and concisely how to create 
a binary executable of the runtime monitoring testing tool 
YR-DB-RUNTIME-VERIF having user defined runtime monitors. 
The guide also specifies keywords allowed within runtime 
monitor specifications as State Diagram Mealy Machines. 


YEROTH_QVGE (YR_QVGE) could be used for the following 
automatic generation, analysis, verification, and validation 
tasks: 


1. Automatic generation of runtime monitoring module 
program to prove whether a test procedure, automated, 
or not, is correct with regards to a test and / or design 
STATE DIAGRAM MEALY MACHINE. 


In effect, let the test execution be runtime monitored to 
watch whether accepting error states would be found. 


For instance, Junit testing environment could 
automatically integrate an automatically generated 
runtime monitor infrastructure for unit testing. 


2. Automatic generation of runtime monitoring module 
program for any software that can emit DBus messages. 


Such runtime monitoring modules are for interest for 
special LTL model checking properties that cannot get 
a definite answer through use of a conventional model 
checker. 


3. Software design properties with SQL 


4. Software design properties including event sequences 
over different layers of software system architecture 


5. Class diagram with sequence diagram. 


2 YEROTH_QVGE (YR_QVGE) Short 
Overview 


Figure 7: YEROTH_QVGE software library dependencies. 


Ihttps://github.com/yerothd/yr_sd_runtime_verif 
2https://github.com/yerothd/yr-db-runtime-verif 
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YR_SD_RUNTIME_VERIF_LANG 


i] 
YR_SD_RUNTIME_VERIF_UNIT_TESTS 


i] 
YR_SD_RUNTIME_VERIF_LANG_ COMP 


t 


YR-DB-RUNTIME-VERIF 


YEROTH_QVGE is a CASE (Computer-Aided Software 
Engineering) design tool to generate "domain-specific 
language (DSL) yYrR_sD_RUNTIME_VERIF_LANG +" files, to be 
inputted into the "compiler yR_sD_RUNTIME_VERIF_LANG_COMP 
"so to generate C++ files for the "runtime verifier tester 
YR-DB-RUNTIME-VERIE 7" that allows for manual verification 
of SQL correctness properties of Graphical User Interface 
(GUI) software. 


Figure 8 illustrates a workflow diagrammatically of the 
afore described process. 


Figure 7 show a diagram of the afore described process; 
The step of the unit tests is colored in gray because it is only 
for developers of YEROTH_QVGE intended. 


YR-DB-RUNTIME-VERIF inputs SQL correctness properties 
expressed using the formalism "state diagram mealy 
machine (YR_SD_RUNTIME_VERIF_LANG )". Figure 6 illustrates 
a software system architecture of YR-DB-RUNTIME-VERIF , 
together with the monitored program under analysis. The 
Free Open Source Code Software (FOSS) tool-chain of 
development testing is located as follows for free, EXCEPT 
for "YEROTH_QVGE "that is a Closed Source Code Software 
(CSCS): 


¢ COMPILER (i.e.: YR_SD_RUNTIME_VERIF_LANG_COMP ): 
https://github.com/yerothd/yr_sd_ 
runtime_verif_lang 


¢ RUNTIME VERIFIER TESTER (i.e.: YR-DB-RUNTIME-VERIF ): 
https://github.com/yerothd/ 
yr-db-runtime-verif 


* state diagram mealy machine UNIT TESTS CODE (i.e.: 


YR_SD_RUNTIME_VERIF_UNIT_TESTS ): 
https://github.com/yerothd/yr_sd_ 
runtime_verif_UNIT_TESTS 


= 


« state diagram mealy machine (i.e.: 
YR_SD_RUNTIME_VERIF_LANG ): 
https://github.com/yerothd/yr_sd_ 


runtime_verif 


3 YEROTH_QVGE (YR_QVGE) Project 
Dependency 


Table 2: YEROTH_QVGE Design and Testing System 
Dependencies 
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PROJECT Required Library 


1) YR_SD_RUNTIME_VERIF_LANG [Sara 
2) YR_SD_RUNTIME_VERIF_LANG_COMP 


3) YR_SD_RUNTIME_VERIF_UNIT_TESTS 
4) YR-DB-RUNTIME-VERIF 


Table 2 illustrates for each library project, which others it 
depends on. 


4 Advantages of YEROTH_QVGE 


A sample state diagram mealy machine is shown in Figure 3. 


WITH manual drawing of SQL CORRECTNESS PROPERTY 
MODEL, you are freed from manually writing "state 
diagram mealy machine text files" that could be tedious and 
lengthy. Also, editing state diagram mealy machine files 
manually could be more error-prone than letting a compiler 
(YR_SD_RUNTIME_VERIF_LANG ) do it for you. 


5 State 
(SDMM) 


Diagram Mealy Machine 


TABLE 1 depicts scientific keywords and their engineering 
counterpart that can be used in describing NOT DESIRABLE * 
SQL * call sequence state diagram mealy machine in 
YEROTH_QVGE Design and Testing System. 


A STATE DIAGRAM mealy machine specification is 
compiled into C++ code that describes a runtime monitor 
to be executed in the runtime monitoring tester yr-pB- 
RUNTIME-VERIF . Figure 3 depicts a sample State Diagram 
Mealy Machine specification on a NOT DESIRABLE SQL call 
sequence. 


5.1 HOWTO READ A "SDMM" 


Figure 2 shows a finite automaton representation of the 
mealy machine description in Figure 3. It shall be read as 
follows: 


¢ The program is ina start state D; state D is a start state 
since there is incoming "START" arrow into it. 


(Pre-) Condition QO: "department name’ YR_ASSET’ 
is not in table column ’department_name’ of 
database table ’ department’ "; applies in state D. 


GUARD CONDITION 


Whenever 


in_sql_event_log(’ DELETE.department .YR_ASSET’, 
STATE (d)): "event ’ DELETE.department . YR_ASSET’ 


appears in SQL event log (trace) leading to state D"; 
applies in state D, system under test (SUT) event 
' SELECT.department’ could occur. 


When SUT event ’SELECT.department’ occurs, 
SUT is now in state E; state E is an error state because 
the node that represents it in Figure 2 has 2 circles on 


it. 
» (Post-) Condition Ql: "department 
name ’YR_ASSET’ is in table column 


3Scientific: fail (forbidden) trace. 
4Structure Query Language. 
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‘department_name’ of database table 


’ stocks’ "; applies in state E. 


This shall not be the case since department 
'YR_ASSET’ is no more defined in SUT database 
table’ department’. 


5.2 "SDMM" WITH MORE THAN 2 STATES 


State Diagram Mealy Machines (SDMM) with more than 2 
states have following characteristics, as detailed in scientific 
and engineering journal paper [Nou23] in preparation: 


¢ Only the first 
specification 


transition has a_ pre-condition 


e Each other transition only has a_ post-condition 
specification 


e Since each state only has 1 outgoing state transition, 
the post-condition of the previous (incoming) state 
transition acts as the pre-condition of the next 
transition. 


6 YEROTH_QVGE 
Workflow 


(YR_QVGE) 


Figure 8: Workflow. 


draw SQL temporal 


safety property with 
YR_QVGE. 


' 


copy ".spec_sd_mealy" generated 
file into YR-DB—-RUNTIME-VERIF 
user project directory: 


"$USER_PROJECT_DIR/sd—mealy—machine-specs". 


' 


Instrument SUT (system uder test) 
with QtDbus calls to 
YR-DB-RUNTIME-VERIF 


' 


GENERATE A SINGLE 
yr—db-runtime—verif executable 
using bash scripts in folder 


"$YR-DB-—RUNTIME-VERIF". 


The "Design and Testing System" YEROTH_QVGE works 
with following workflow, as illustrated graphically in 
Figure 8: 


1. Draw Structure Query Language (SQL) temporal safety 
property using drawing tool YEROTH_QVGE; 
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2. copy the generated ".spec_sd_mealy" files into a user 
project directory in YR-DB-RUNTIME-VERIF home 
development folder: "SYR-DB-RUNTIME-VERIF"; 


3. follow the steps described in Section 7 so to gather 
a single executable that defines all specified runtime 
monitors. 


7 Custom User Project (YR-DB- 


RUNTIME-VERIF) 


Table 3: yR-DB-RUNTIME-VERIF Directories 


Variable for illustration purposes 


SYR-DB-RUNTIME-VERIF 
SYR-DB-RUNTIME-VERIF/SUSER_PROJECT 


Meaning 


root directory of YR-DB-RUNTIME-VERIF 


root directory of user project 


Table 3 illustrates directories that will be used to describe a 
process to generate a single binary executable for a user's 
custom project with several runtime monitor specifications. 


Figure 5 illustrates a screenshot of the Graphical User 
Interface (GUI) of yR-DB-RUNTIME-VERIF . You can get a copy of 
YR-DB-RUNTIME-VERIF using the following command: 

git clone https://github.com/yerothd/yr-db-runtime-verif 


Creating a binary executable for State Diagram Mealy 
Machine (SDMM) specifications consists of the following 
elements: 


1. ’MariaDB’ database connection configuration file: 
this file defines settings to connect to the system under 
test (SUT) application database; it is located in path: 
"$YR-DB-RUNTIME-VERIF/YR-DB-RUNTIME-VERIF-GUI-ELEMENTS- 


SETUP/yr-db-runtime-verif-database-connection.properties". 


A database connection to the SUT application 
database iis required in order to check LTL 
property through the SDMM application library 
YR_SD_RUNTIME_VERIF_LANG . 


2. Property configuration file: this file defines environment 
variables necessary for building a binary executable 
for the user; it is located in path: "$yR-DB-RUNTIME- 
VERIF/SUSER_PROJECT/bin/configuration-properties.sh". 
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3. "SYR-DB-RUNTIME-VERIF/SUSER_PROJECT/sd-mealy-machine-specs": 
this directory contains user defined State Diagram 
Mealy Machine (SDMM) specifications to generate 
Corresponding runtime monitors within a single binary 
executable. 


4. Generate an executable for a user defined runtime 
monitor: 


a) execute following command in directory “$yr-pB- 
RUNTIME-VERIF": 


./YR-create-executable-for-user-SDMM.sh -d SUSER_PROJECT 


b) modify the LTL verification code part within the 
generated source code files. 


Then execute following command in directory "$yR-DB- 
RUNTIME-VERIF": 


./yr_db_runtime_verif_BUILD_DEBIAN_PACKAGE.sh 


c) uninstall yR-DB-RUNTIME-VERIF with following command 
in directory "$yYR-DB-RUNTIME-VERIF": 


./yc_DB_RUNTIME_VERIF_uninstall.sh 


d) re-install yr-DB-RUNTIME-VERIF with following command 
in directory "$yR-DB-RUNTIME-VERIF": 


./yc_DB_RUNTIME_VERIF_INSTALL.SH 


8 HOW TO START YR-DB-RUNTIME- 
VERIF 


* The "ELF-x64" binary executable, in the source 
development directory is located in full path: "SYR- 
DB-RUNTIME-VERIF/bin". 


« The DEBIAN-LINUX icon |_| Of YR-DB-RUNTIME- 
verIF is located in "Applications" menu under section 
"Programming", and section "Accessories". 


¢ The "ELF-x64" binary executable, after installation 
of the DEBIAN-LINUX package 'yr-db-runtime- 
verif.deb’ is located in full path: "/opt/yr-db-runtime- 
verif/bin". 
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Figure 9: SAMPLE sql recovery state diagram model in YEROTH_QVGE 


FINAL_STATE_AUTO(E): 
IN_POST(YR_ASSET_cat, 
stocks.categorie): 
recovery_sql_query(categories, INSERT INTO cat 
values (yr_id, YR_ASSET_cat’, YR_ASSET )’). 


START_STATE(YR); 
NOT_IN_PRE(Y 


ies (id, nom_categorie, nom_departement_produit) 


[in-set_trace(‘DELETE.categories.YR_ASSET_cat’, STATE(YR))] / 'SELECT.stocks' 


/ ASSET_cat, 


iés.nom_categorie) 


9 SQL QUERY Recovery execution on 
demand 


A user can specify which SQL command query to execute 
whenever a System Under Test (SUT) lands in an accepting 
error state. This is done using keywords ending with 
"AUTO", used for meaning "AUTO RECOVERY FROM FAIL 
STATE": 


1. recovery_sql_query 


2. END_STATE_AUTO 


3. FINAL_STATE AUTO 


4. ERROR_STATE_AUTO. 


The use of an "AUTO" keyword shall be accompanied 
with a use of keyword recovery_sgql_query, that 
specifies a SQL command query to run when landing in this 
fail error accepting state. 


9.1 Automatic SQL Command Query Generation 


YEROTH_QVGE implements an automatic SQL query 
generation strategy in case a user don't specify a 
SQL command query, since it could be leaved empty: 
Subsections 9.1.1, 9.1.2, 9.1.3, and 9.1.4 describe the 
strategy implemented. 


9.1.1 ERROR ACCEPTING STATE for sdmm 1. 


not in_before (YX, YY) ACTION (V) 
in_after (DD, YR) 


9.1.2 RECOVERY 1. 


in_after (DD, YR) | ACTION (RECOVERY_ND) 
not in_after (DD, YR) 
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9.1.3 RECOVERY 2 (Practical solution to be implemented 
in YR-DB-RUNTIME-VERIF. 


in_after (DD, YR) | ACTION (RECOVERY_D) 
in_after (YX, YY) 


9.1.4 Concrete RECOVERY 2 action. 


in_after (YX, YY) | insert_RECOVERY (YX, YY) 
e 
in_before (YX, YY) 


10 Formal Scientific and Engineering 
Project Description 


Detailed formal scientific and engineering contributions 
of design and testing system YEROTH_QVGE can be 
found in JOURNAL ARTICLE "Runtime Verification Of 
SQL Correctness Properties with YR-DB-RUNTIME- 
VERIF" [Nou23]. 


11 Conclusion 


The graphical drawing tool YEROTH_QVGE (Figure 4) costs 
only 3,000 EUROS. WE ONLY SUPPORT DEBIAN-LINUX 
(https: //www.debian.org). 


References 
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Table 1: EQUIVALENCES 


scientific literature | engineering acronym 


POST AFTER 


A TRACE AN EVENT LOG 
A FINAL STATE AN ERROR STATE 


Figure 1: A motivating example, as previous bug found in YEROTH—ERP-3.0. 
QO := NOT_IN_BEFORE(YR_ASSET, department.department_name). 


a := IN_AFTER(YR_ASSET, stocks.department_name). 


foo [in_sql_event_log(’DELETE.department.YR_ASSET’, STATE(D))] / "SELECT.department’ 
start — 
(a) 


Figure 2: ASAMPLE state diagram mealy machine file. 


1. yr_sd_mealy_automaton_spec yr_missing_department_NO_DELETE 
2. { 
3. START_STATE(d) :NOT_IN_BEFORE(YR_ASSET , department .department_name) 
4. ->[in_sql_event_log(’DELETE.departement .YR_ASSET’ , STATE(d))]/’SELECT. department’ -> 
5. ERROR_STATE(e) : IN_AFTER(YR_ASSET, stocks.department_name) . 
6. } 
Figure 4: ASCREENSHOT OF yr-bB-RUNTIME-VERIF 
Figure 3: ASCREENSHOT OF YEROTH_QVGE. SQL EVENT LOG. 
norne/yer/Downtoads/YRyimagesiye. sd ruritirne veri, language EXAMPLE gr - VR-Gt Visual Grapt) Editor 0.YR,0(64bit) YR-DB-RUNTIME-VERIF _ console ne es 
le EGR Select View Grapnviz Window Help 
Ca & *e © O B rk = Ho oR 


New Gpen Save Undo Cut Copy Paste Delete Find  Selectitems CreateNodes Transform Factor 


/ ‘SELECT.department Custom Attributes: 3 
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1 Developer Biography 


if bik 


Figure 5: Portrait of XAVIER. 


PROF. DR.-ING. DIPL.-INF. XAVIER NOUNDOU is a 
CHRISTIAN BY FAITH, Cameroonian, born on September 16 
1983 in DOUALA (LITTORAL region, CAMEROON). Xavier 
has a “Diplom—Informatiker (Dipl.—Inf.)” qualification from 
the University of Bremen, Bremen, Bremen, GERMANY 
(May 25, 2007). XAVIER NOUNDOU IS A PHILOSOPHIAE 
DOCTOR (PH.D.) from THE UNIVERSITY OF WATERLOO 
(ON, CANADA); DECEMBER 20, 2011! 


PROF. DR.-ING. DIPL.-INF. XAVIER NOUNDOU 
has worked together with PROF. DR. RER. NAT. HABIL. 
JAN PELESKA, at AGBS-University of Bremen, GERMANY; 
and 2 years later at WatForm—University of Waterloo, ON, 
Canada, with PATRICK LAM, PH.D. (MIT, BOSTON, MA, 
USA), P.ENG. (Ontario, CANADA). 


Xavier could successfully work with DR. FRANK TIP 
at The University of Waterloo (Waterloo, ON, Canada) on his 
first JAVA dynamic program analysis. 


Xavier also had the great opportunity through DR. 
MARCEL MITRAN and PATRICK LAM, PH.D., P.ENG.; 
to work as a graduate intern in Markham (Toronto, ON, 
CANADA) at IBM TORONTO SOFTWARE LABORATORY; 
in the JAVA-J9 Just—In—Time Compiler Optimization Team, 
together with VIJAY SUNDARESAN, M.Sc (McGill Univer- 
sity, QC, Canada). 


Xavier has following academic and professional en- 
gineering research contributions: 


1. ’Statistical test case generation for reactive systems’ 
at RTT-MBT at VERIFIED SYSTEMS INTERNATIONAL 
GmbH (https://www.verified.de). 


2. 'Context-Sensitive Staged Static Taint Analysis For C 
using LLVM' 


1. source code in C++: 
https://github.com/sazzad114/saint 


2. fulltext: https: //zenodo. org/record/8051293 


3. 'YEROTH-ERP-3.0’: 


1. source code in C++: 


lnttps://github.com/yerothd/yr_sd_runtime_verif_lang 
2https://github.com/yerothd/yr-db-runtime-verif 
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a. YEROTH-ERP-3.0: 
https://github.com/yerothd/ 


yeroth-erp-3-0 


b. YEROTH-ERP-3.0 SYSTEM DAEMON: 
https://github.com/yerothd/ 


yeroth-erp-3-0-system-daemon 


2. full text (ongoing publication): 
https: //zenodo.org/record/8052724 


2. Introduction 


Figure 6: SOFTWARE ARCHITECTURE OF YR-DB- 
RUNTIME-VERIF. 


QT socket calls (via Qt—Dbus) t t 


SUT source code instrumented 


MYSQL library methods calls t t 


OS system calls tt i 


YEROTH_QVGE is a 


CASE (Computer-Aided 


Software Engineering) design tool to generate 
"domain-specific language (DSL) —YR_SD_RUNTIME_VERIF_LANG 
1" files, to be inputted into the "compiler 
YR_SD_RUNTIME_VERIF_LANG_COMP "so to generate 
C++ files for the runtimeverifiertester "yr-pB- 


RUNTIME-VERIF 2" that allows for manual verification of 


SQL correctness properties of Graphical User Interface (GUI) 


software. 


YR-DB-RUNTIME-VERIF inputs SQL correctness properties ex- 
pressed using the formalism state diagram mealy machine 
(YR_SD_RUNTIME_VERIF_LANG ). Figure 6 illustrates a software 
system architecture of YR-DB-RUNTIME-VERIF , together with the 
monitored program under analysis. The Free Open Source 
Code Software (FOSS) tool-chain of development testing is 
located as follows for free, EXCEPT for "YEROTH_QVGE " 
that is a Closed Source Code Software (CSCS): 


¢ COMPILER (i.e.: YR_SD_RUNTIME_VERIF_LANG_COMP ): 
https://github.com/yerothd/yr_sd_runtime_ 


verif_lang 

RUNTIME VERIFIER TESTER (i.e.: YR-DB-RUNTIME-VERIF ): 
https://github.com/yerothd/ 
yr-db-runtime-verif 

state diagram mealy machine UNIT TESTS CODE (i.e.: 


YR_SD_RUNTIME_VERIF_UNIT_TESTS ): 
https://github.com/yerothd/yr_sd_runtime_ 


verif_UNIT_TESTS 
state diagram mealy 


YR_SD_RUNTIME_VERIF_LANG ): 
https://github.com/yerothd/yr_sd_runtime_ 


verif 


machine (i.e.: 
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3 YEROTH_QVGE (YR_QVGE) Project 
Dependency 


Table 2: YEROTH_QVGE Design and Testing System De- 
pendencies 


PROJECT Required Library 


1) YR_LSD_RUNTIME_VERIF_LANG 
2) YR_SD_RUNTIME_VERIF_LANG_COMP 


3) YR_SD_RUNTIME_VERIF_UNIT_TESTS 


4) YR-DB-RUNTIME-VERIF 


Table 2 illustrates for each library project, which others it de- 
pends on. 


Figure 7: YEROTH_QVGE software library dependencies. 


YR_SD_RUNTIME_VERIF_LANG 


t 


YR_SD_RUNTIME_VERIF_UNIT_TESTS 


' 


YR_SD_RUNTIME_VERIF_LANG_ COMP 


t 


YR-DB-—RUNTIME-VERIF 


Figure 7 show a diagram overview of the presentation in Ta- 
ble 2. The step of the unit tests is colored in gray because it 
is only for developers of YEROTH_QVGE intended. 


4 Potential Uses of YEROTH_QVGE 


YEROTH_QVGE (YR_QVGE) could be used for the follow- 
ing automatic generation, analysis, verification, and valida- 
tion tasks: 


1. Automatic generation of runtime monitoring module pro- 
gram to prove whether a test procedure, automated, or 
not, is correct with regards to atest and /ordesign STATE 
DIAGRAM MEALY MACHINE. 


In effect, let the test execution be runtime monitored to 
watch whether accepting error states would be found. 


For instance, Junit testing environment could automati- 
cally integrate an automatically generated runtime mon- 
itor infrastructure for unit testing. 


2. Automatic generation of runtime monitoring module pro- 
gram for any software that can emit DBus messages. 
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Such runtime monitoring modules are for interest for spe- 
cial LTL model checking properties that cannot get a defi- 
nite answer through use of a conventional model checker. 


3. Software design properties with SQL 


4. Software design properties including event sequences 
over different layers of software system architecture 


5. Class diagram with sequence diagram. 


5 Advantages of YEROTH_QVGE 


Figure 8: Workflow. 


draw SQL temporal 


safety property with 
YR_QVGE. 


t 


copy ".spec_sd_mealy" generated 
file into YR-DB—-RUNTIME-VERIF 
user project directory: 


"$USER_PROJECT_DIR/sd—mealy—machine-specs". 


' 


Instrument SUT (system uder test) 
with QtDbus calls to 
YR-DB-RUNTIME-VERIF 


' 


GENERATE A SINGLE 
yr—db-runtime—verif executable 


using bash scripts in folder 
"$YR-DB-—RUNTIME-VERIF". 


A sample state diagram mealy machine is shown in Figure 2. 


WITH manual drawing of SQL CORRECTNESS PROPERTY 
MODEL, you are freed from manually writing "state dia- 
gram mealy machine text files" that could be tedious and 
lengthy. Also, editing state diagram mealy machine files 
manually could be more error-prone than letting a compiler 
(YR_SD_RUNTIME_VERIF_LANG_CompP ) do it for you. 


6 Conclusion 


YEROTH_QVGE costs only 3,000 EUROS. WE ONLY SUP- 
PORT DEBIAN-LINUX (https: //www.debian. org). 
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YEROTH-—ERP-3.0 
SOFTWARE SYSTEM ARCHITECTURE 


PROF. DR.—ING. DIPL.-INF. XAVIER NOUNDOU 


This document describes the thick client software system architecture of YEROTH- 
ERP-3.0. This document also explains the reasons for which we chose to design and 
implement YEROTH-ERP-3.0 as a thick client software system, as opposed to currently 
more popular webbrowser based software system. 


This document further demonstrates the superiority, in terms of simplicity, speed, 
maintenance, and low costs of development of thick client software system architectures 
over webbrowser based software system architectures ! 


1. YEROTH-ERP-3.0, source code (no executable binary): 
https: //github.com/yerothd/yeroth-erp-3-0 


2. YEROTH—ERP-—3.0-SYSTEM—DAEMON, source code (no executable 
binary): 
https: //github.com/yerothd/yeroth-erp-3-0-system-daemon 


3. YR-DB-RUNTIME-VERIF: 
https://github.com/yerothd/yr-db-runtime-verif 


4. YR_SD_RUNTIME_VERIF: 


https: //github.com/yerothd/yr_sd_runtime_verif 


Version: November 7, 2023. 
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Chapter 1 


Introduction 


This introduction motivates why | created YEROTH-ERP-3.0, and why it 
uses the best software programming language AND METHODOLOGY (OOP: 
OBJECT-ORIENTED PROGRAMMING) of its time! 


1.1 Motivation 


Figure 1.1: Business manager’s main window 


YEROTH-ERP-3.0 - user window - x 


Functions Tools Help 


ae = B oO 


HR financial 
SUPPLIERS expenses 


ASSETS 
(Rental) / 
Stocks 


Ricinase ASSET / Stock 
Payments Decktoeed transfer AND / 
OR checkout 


database ip address: "localhost" - database table: "yeroth_erp_3" - database options: "" 


Merchandise / 
SERVICES 


YEROTH-—ERP-3.0 [NOU22, NOU21a, NOU21b] is an Enterprise Resource Planing 
(ERP) software system that aims ‘effectiveness’ and ‘simplicity’, compared to other 
high ranked ERP software systems (e.g.: ‘Sage Gescom i7’, 'SAP Business One’, 'Odoo’, 
etc.). 


YEROTH-ERP-3.0 is implemented by me with THE USER INTERFACE LIBRARY 
QT [Ltd22]. Our goal when designing and implementing this ERP software system is 
morefolds: 
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1) RENDER ENTERPRISE RESOURCE PLANING (ERP) SOFTWARE SYSTEM USAGE 
AND MANIPULATION AS EASY AS READING A LEISURE OR RECREATIONAL 
BOOK SO TO REDUCE USER STRAIN SIZE! 


2) CONTRIBUTE TO REDUCE POVERTY BY IMPROVING SOFTWARE SYSTEM 
TECHNOLOGY FOR ENTERPRISE RESOURCE PLANING (ERP). 


1.1.1 Application Domain 


YEROTH-ERP-3.0 can be used by any managerial organization, WHETHER govern- 
mental, OR NON GOVERNMENTAL (N.G.O) ! 


YEROTH—ERP-3.0 is aimed at being simpler in usage and manipulation than older top 


ranked ERP software systems (e.g.: ‘Sage Gescom i7’, ‘SAP Business One’, Odoo, etc.) 
! 


A DETAILED COMPARISON OF OCCURS IN PAPER [NOU 21a]! 
Applications domains of YEROTH-—ERP-3.0 are for instance: 

1. engineering offices; 

2. insurance companies; 

3. attorney offices; 


4. etc. 


1.1.2 Implementation Technology 


Table 1.1: COMPARISON TABLE BETWEEN C++ [Ste90], JAVASCRIPT [Fla20], AND 
JAVA [AGHOO]. JAVASCRIPT and JAVA only have virtual machines that are in FACT RE- 
ACTIVE SYSTEMS! 


FEATURES C++ Javascript Java 
1. PROGRAMMING LANGUAGE PHILOSOPHY object-oriented | object-oriented | object-oriented 
2. MACROS Vv Vv 

3. MULTIPLE INHERITANCE Vv 

4. support INTERFACES W Vv Vv 
5. STATIC COMPILATION Vv 

6. VM 7 INTERPRETATION AND MANAGEMENT Vv W 
7. UNIT TESTING FRAMEWORK Vv Vv Jv 
8. NETWORK CAPABLE Vv Vv Vv 
9. CROSS PLATFORM PORTABLE Vv Vv Vv 
10. include FILE LIBRARY CAPABILITY Vv 

11. MULTI THREADING Vv Jv 
12. WYSIWYG GUI DESIGN TOOL Vv JV 
13. VIRTUAL MACHINE IS A REACTIVE SYSTEM Vv Vv 


We chose to design and implement YEROTH-—ERP-3.0 as a thick client software system 
because of the following reasons: 


1. The implementation language C++ offers much flexibility: 
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1. MULTIPLE INHERITANCE: 


It allows developers to abstract as much as possible business code upwards, away 
from downwards implementation classes. For instance, in YEROTH—ERP-3.0, 
GUI Qt windows inherits for instance search filtering feature, and print capability 
from 2 different classes. 


Print capability couldn't be inherited from the same class where search filtering 
is abstracted and partially implemented (interface in JAVA for instance doesn’t 
allow any method body code), because it works in its pure abstract class (C++ 
class with at least 1 empty method body), together with feature database column 
filtering for viewing and printing. 


The drawback of the multiple inheritance in C++ is: it sometimes can be very 
difficult to build it using "gcc (g++) [GCC]"! 


2. MACROS: 
They enable developers to create TEXT TEMPLATE in their code. 


For instance, | use macros in some parts of my code to reduce execution time and 
stack activation records size for method or function calls in YEROTH—ERP-3.0! 


2. The availability of >WHAT YOU SEE IS WHAT YOU GET’ (WYSIWYG) tools for fast 
and useful user interface design (e.g.: Qt designer [Com20], miniStudio 
(vxWorks) [WEI20], etc.) 


3. The low number of logical software system architecture layer (i.e.: 2.) involved with 
the use of a thick client software system architecture, as opposed to a webbrowser 
based software system (i.e.: 4, client user interface, presentation layer, business 
logic, and data (DBMS)). 


FURTHERMORE, TABLE 1.1 ILLUSTRATES A FEATURE COMPARISON TABLE BE- 
TWEEN object oriented languages C++, JAVASCRIPT, and JAVA! 
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1.1.3 Software System Current Metrics 


Table 1.2: YEROTH—ERP-—3.0 RELEVANT SOFTWARE SYSTEM METRICS 


Software System Metric Value 


User Interface (windows, dialog) number 60. 
MariaDB SQL table number 


MariaDB SQL table column number 320 


Latex template for PDF printing 
Source lines of code (SLOC) 330, 000 


1.2 Overview 


This pamphlet is structured as follows: 


1. 


Chapter 1 motivates why | created YEROTH-ERP-3.0, and why it uses the best soft- 
ware programming language AND METHODOLOGY (OOP: OBJECT-ORIENTED 
PROGRAMMING) of its time ! 


. Chapter 2 tabular evaluates why thick client are BETTER THAN webbrowser based 


software system architectures ! 


. Chapter 3 explains why YEROTH-—ERP-3.0 is modular in its uses, and fits any indus- 


trial setting. 


. Chapter 4 explains why YEROTH—ERP-3.0 uses the BEST SOFTWARE TECHNOL- 


OGY IN TERMS OF SOFTWARE SYSTEM ARCHITECTURE ! 
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Chapter 2 


Thick Client VS. Webbrowser based 
Software System Architecture 


This comparison chapter tabular evaluates why thick client are BETTER THAN 
webbrowser based software system architectures ! 


2.1 Thick client: 2 layers logical software architecture 


Figure 2.1: 2 layers logical architecture of thick client software system (Image copied 
from [sec20]). 


Database 


2.2 Webbrowser based: at least 4 layers logical software 
architecture 


Figure 2.2: 4 layers logical architecture of webbrowser based software system (Image 
copied from [KM06)]). 


TIER 1 | TIER 2 TIER 3 
HTTP Response Response Return Results 
Google 
1 Exetute 
e Bf ipo" 
= = 
\ ¢ \ id \ 14 
& HTTP Request Invoke Component Invoke Query 
f : nat 
IP Services | Application 
a | ae 
8 Web Server | Application 


Database Server 
Server I 
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2.3. Tabular Comparison Between Thick-Client And Web- 
browser based Architecture 


Table 2.1: Thick client application VS Webbrowser based application. 


Thick client application Vv Webbrowser based application 
business code user interface application server 
co-related software systems 1 (DBMS) at least 3 (DBMS, web / application server) 
number of logical layers 2 (client and data) 4 (client, presentation, logic, and data) 
rapid prototyping (WYSIWYG tools) yes very limited 
software security vulnerability low (1 programming language) VERY high (several programming languages) 
user interface all computers (GUI with BUSINESS CODE) all computers (web—browser) 


Table 2.1 compares thick client software systems against webbrowser based software 
systems. 


Table 2.1 ALSO ILLUSTRATES ADVANTAGES of thick client software system architec- 
ture over webbrowser based software system architecture ! 


The common argument for webbrowser based software system architecture is you up- 
date the business code just at 1 place: the application server! 


| argue that thick client architecture IS JUST AS WELL BEST UPDATED AT 1 PLACE: 
the user's computer. 


FOR INSTANCE, UPDATE OR UPGRADE OF ENTERPRISE SOFTWARE SYSTEM 
WEBBROWSER BASED REQUIRES ALMOST AT LEAST 1 24 HOURS SHUTDOWN OF 
ALL INVOLVED WEB (apache tomcat, etc.) APPLICATIONS SERVERS. 


The issue of automatic software upgrade in a computer network is best solved by 
the ‘apt upgrade software system of Debian-Linux’, as an example ! 
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Chapter 3 


The Thick Client Software System 
Architecture of YEROTH-ERP-3.0 


This chapter explains why YEROTH-—ERP-3.0 is modular in its uses, and fits any 
industrial setting ! 


Table 3.1: Thick client application VS Webbrowser based application. 


Thick client application v Webbrowser based application 
business code user interface application server 
co-related software systems 1 (DBMS) at least 3 (DBMS, web / application server) 
number of logical layers 2 (client and data) 4 (client, presentation, logic, and data) 
rapid prototyping (WYSIWYG tools) yes very limited 
software security vulnerability low (1 programming language) high (several programming languages) 
user interface all computers (GUI with BUSINESS CODE) all computers (web—browser) 


3.1 Business and user interface code deployment 


Table 3.1 depicts the issue of business and user interface code deployment on all com- 
puters participating in the functioning of YEROTH-—ERP-3.0, as a software system fora 
user. 


We tackle the problem of automatic deployment of business and user inter- 
face code on all user computers by using the ‘apt upgrade’ software system on 
‘Debian-Linux [DEB22]’. 


3.2 Databases 


DBMS MySQL [Mar22] is used for storing and managing huge data across globe. 


3.3. NUMBER OF LOGICAL SOFTWARE SYSTEM LAYERS: 
E.G. Sample technical configurations 


This section illustrates 2 different possible computer network configurations that could 
prevail in industry. 
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3.3.1 Sample 2 computers store 


Figure 3.1: Sample 2 computers store. 


BIG-BOSS—SOFTW 4RE-¥ EROTH—-ERP-3.0—-DR. 


LAN-2-COMPUY, —STORE 


3.3.2 Sample decentralized multi sites supermarket 


Figure 3.2: Sample decentralized multi sites supermarket. 


BIG-BOSS-SOFTWARE-YEROTH-EAP-23.0-0R. 


MANAGER SOFTWARE YEROTH -EAP-2.0 | 
eee > 


MTN-OTHERS-DECENTRAUZED-COMPUTER-NET WORKS-FOR -ET S-KENFACK 


DIGITALOCEAN. COM RACK-SERVERS- XEON-DESKTOPS~ DEDICA TED- CPUs 


P 
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Chapter 4 


Conclusion 


This conclusion explains why YEROTH-—ERP-3.0 uses the BEST SOFTWARE 
TECHNOLOGY IN TERMS OF SOFTWARE SYSTEM ARCHITECTURE ! 


Table 4.1: YEROTH-—ERP-3.0 VS. Odoo. 


YEROTH-ERP-3.0 Odoo 
libraries & programs 1lxqt-sudo, etc. python-lxml, etc. 
user interface code TOOLS WYSIWYG = QT-DESIGNER = (CUSTOM BUILD) FRAMEWORKS 
business code C++ Python, JavaScript 
Database Management Server (DBMS) MySQL PostgreSQL 
web server Werkzeug 


YEROTH-ERP-3.0 has a thick client software system architecture because we found 
thick client software system architectures simpler than webbrowser based software 
system architectures. 


Thick client software system architectures is simpler because it requires less layers 
in its logical (or physical) software system architecture, and is easier to develop and 
maintain as a software system application. 


Table 2.1 illustrates a thick client software system is SUPERIOR IN TERMS OF TOOLS 


FOR MAINTENANCE AND DEVELOPMENT than a webbrowser based software system 
! 


A webbrowser based software system architecture has more drawbacks as fol- 
lows: 


1. it requires at least 2 other software systems, apart from the ones normally required 
by developed software system itself, for instance libraries (e.g.: Log4j), to fully op- 
erate (e.g.: web server, application server, etc.). 


Table 4.1 depicts this situation in the light of the open source ERP software system 
Odoo. 


Accordingly, a thick client software system doesn’t require any running and manag- 
ing infrastructure such as for example an application server ! 


2. A webbrowser based software system requires at least 4 layers in its logical system 
architecture (e.g.: client, presentation, logic, and data layers). 


Accordingly, a thick client software system only requires at least 2 layers ! 
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3. Awebbrowser based software system potentially entails more software security vul- 
nerabilities because its implementation requires the use of at least 2 different pro- 
gramming languages, and frameworks in combination. 


Accordingly, a thick client software system needs only the use of 1 homogeneous 
software programming language ! 
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Appendix A 


Presentation Documents of open source 
software system YEROTH-ERP-3.0 
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YEROTH-ERP-3.0 Software Sys- 
tem Product Sheet 


YEROTH-ERP-3.0 is an ERP software system with 6 user 
roles, and types: 

. « Administrator » 

. « Business manager » 

. « Cashier » 

. «Seller » 

« ASSET — stock manager » 

. « Storekeeper ». 


YEROTH FAP AG tay wnten 


AuURWNE 


YEROTH-ERP-3.0 features: 

1. alerts over stock quantity, and, time period 

2. business dashboard 

3. HR (human resources), customer relationship manage- 
ment (CRM), budget line management 

. sale management (e.g. point of sale) 

. ASSET — stock management (e.g. check in) 

. user, and role administration 

. wildchar searches with character %. 


Business manager's main window 


YEROTA ERP 35 fade sabe FO [pet eeee pase erat) 


NOW SS 


YEROTH-ERP-3.0 is: 

1. easier, and, intuitiver, in its use 

2. lighter, and, faster, in memory usage 
3. multi sites. 


YEROTH-ERP-3.0’s runtime memory usage test is realized 
using run-time software analysis tool valgrind. 
GENERAL SOURCE CODE QUALITY CONTROL is realized 


with compile-time code analysis tool Cppcheck. Cashier's main window 
OPERATIONS 
Point of Sale Hardware Database Management Operating Systems 
JV Barcode scanner Systems JV Debian-Linux 
Vv Thermal printer, etc. VY MySQL 


Author: PROF. DR.-ING. DIPL.-INF. XAVIER NOUMBISSI NOUNDOU Version of — October 30, 2023 - 
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Advantages of YEROTH-ERP-3.0 
Compared to other top ERP Soft- 
ware Systems 


YEROTH-ERP-3.0 is a very easy touse ERP (Enterprise Re- preparer 
source Planing) software system because of its characteris- — 
tics: 

. separate views for each user role 

. complete and fundamental training in 5 days 

. easy to use graphical user interface (GUI) 

. no college or university training needed 

. no formal business training needed 

. no financial accounting training needed 


NOU BP WN PB 


. no internet connection needed. 


Stock listing window 


Table 1 pictures the ‘effectiveness’ and ‘simplicity’ of YEROTH-ERP-3.0, compared to other top 
ERP software systems "Sage Gescom i7”, and "SAP Business One”. 


YEROTH-ERP-3.0 Sage Gescomi7 SAP Business One 


separate views per user role YES VES YES 
complete training (or solution) at least 2 weeks at least 2 months at least 3 months 
difficulty in navigation easy very difficult very difficult 
usage language in software easy everyday English simple technical 
financial accounting knowledge no no useful 
advanced marketing knowledge no useful useful 
internet connection optional optional optional 


Table 1: Comparison between YEROTH-ERP-3.0 and 2 top tier—1 full featured ERP software sys- 
tems 


OPERATIONS 
Point of Sale Hardware Database Management Operating Systems 
Vv Barcode scanner Systems JV Debian-Linux 
Vv Thermal printer, etc. ¥ MySQL 


Author: PROF. DR.-ING. DIPL.—INF. XAVIER NOUMBISSI NOUNDOU Version of — October 30, 2023 - 
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YEROTH-—ERP-3.0 Point Of Sale 
Recommended Hardware 


1 Barcode Scanner 
We recommend, but not exclusively, the use of barcode 
scanner: " Xfox FJ-5 USB Plug and Play Automatic Bar- 


code Scanner " (approx. 17€). a dae 
arcode Scanner 


2 Thermal Printer : 
ALL EPSON THERMAL PRINTERS! 


We recommend, but not exclusively, the use of thermal 
printer: " Epson TM T20ii Point of Sale Thermal Printer” Thermal Printer 
(approx. 100€). 


3 Cash Drawer 


We recommend, but not exclusively, the use of cash 


drawer: " HP QT457AT ” (approx. 90 €). Cash Drawer 


4 Touch Screen Monitor 


We recommend, but not exclusively, the use of touch 
screen monitor: " ASUS 15.6" LCD Monitor (VT168H) ” 
(approx. 155€). 


Touchscreen Monitor 


5 Computer 


We recommend, but not exclusively, the use of desktop 
computer: ” Lenovo Thinkcentre M720 Small Form Fac- 
tor (SFF) ” (approx. 450€). 


Computer 


6 MULTIUSER TERMINAL Computer (*) 


We recommend, but not exclusively, the use of multi user 
terminal computer: ” NC-300 Multi User Terminal Com- 


puter” (approx. 112€). Multi User Terminal Computer 


V PECULIARITIES IN CERTAIN COUNTRIES AND/OR REGIONS USAGE OF POINT-OF-SALE (THER- 


MAL) PRINTERS REQUIRES ALSO ACQUISITION OF A GOVERNMENT-SOLD DEVICE FOR RECORDING AND CERTI- 
FYING ALL FINANCIAL TRANSACTIONS BETWEEN THE THERMAL PRINTERS AND/OR YEROTH-ERP-3.0(e.g.: GER- 
MANY, CANADA, etc.). 
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Information Brochure of the 


ERP software system 


YEROTH 


—ERP-3.0 


Dr.-Ing. Xavier Noumbissi Noundou 


Tasks « Business manager » 


« Seller » « ASSET - stock manager» «Storekeeper» «Cashier » 


create a department Vv 


insert 1 ASSET, stock, or service 


¥ 


(SERVICE) V (ASSET / STOCK) 


delete ASSET, stock 


view ASSET, stock 


Vv 


modify ASSET, stock 


transfer ASSET, stock 


alich ads 


arr ra 


check-out ASSET, stock 


modify ASSET, stock 
management strategy 
(e.g.: « FIFO », etc.) 


rae 


J (NO PERMANENT) 


JV (NO PERMANENT) 


point of sale 


v 


view ASSET, stock transfers 


purchase management 


Vv 
# V (PARTIAL) 


supplier management 


v 


customer relationship management (CRM) 


, 


(PARTIAL) 


business dashboard 


sale return 


alelelcdaded ada 


view sales information 


V (SELF) 


Table 1: YEROTH-—ERP-3.0 functions—tasks, and associated users—roles. 


1 Developer Biography 


iid 


Figure 1: Portrait of Dr.-Ing. XAVIER. 


Dr.-Ing. Xavier Noumbissi Noundou_ is a CHRISTIAN 
BY FAITH, Cameroonian, born on September 16 1983 in 
DOUALA (LITTORAL region, CAMEROON). 


Xavier has a “Diplom—Informatiker (Dipl.—Inf.)” qualifica- 
tion from the University of Bremen, Bremen, Bremen, GER- 
MANY (May 25, 2007). 


XAVIER NOUMBISS| NOUNDOU IS A PHILOSOPHIAE 
DOCTOR ABD (PH.D. ABD) from THE UNIVERSITY OF WA- 
TERLOO (ON, CANADA); DECEMBER 20, 2011! 


Xavier has following academic research and professional en- 
gineering contributions: 
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. 'Context-Sensitive Staged Static Taint Analysis For C 
using LLVM’ 


1. source code in C++: 


http: //github.com/sazzad114/saint 
http://archive.org/download/ 


2. fulltext: yeroth-saint-2021-MARCH-01/ 
YEROTH-SAINT-2021-MARCH-01.pdf 


. 'YEROTH-ERP-3.0’: 
1. source code in C++: 


a. YEROTH-ERP-3.0: 
http://drive.google.com/file/d/ 
1-JJke20aa_ful j 3twWsBkj3-KRxgZL4q/ 
view?usp=share_link 

. YEROTH—-ERP-3.0 SYSTEM DAEMON: 
http: //drive.google.com/file/d/1ikn5_ 


1KvWPkFDOVxA8eGvk-kul08L-_T/view?usp= 


share_link 
2. full text (ongoing publication): 


http: //archive.org/download/ 
yeroth-erp-pgi-compendium_202206/ 
YEROTH_ERP_PGI_COMPENDIUM. pdf 


2 


YEROTH-ERP-3.0 is an Enterprise Resource Planing (ERP) 
software system. 


Users of YEROTH-ERP-3.0 could have the following 
roles: 


Introduction 
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. « Administrator » 

. « Business manager » 
. « Cashier » 

. « Seller » 


. « ASSET — stock manager » 


An nN BF WN BP 


. « Storekeeper ». 


YEROTH-ERP-3.0 allows for business management tasks 
(listed in Table 1), depending on user role, as follows: 


. create a department (e.g.: finance, asset, stock, etc.) 
. Manage clients, and human resources, and suppliers 
. Manage enterprise asset (e.g.: cars, etc.) 

manage financial expenses 

manage inventory stock 


. Manage sales 


NOU BR WN PB 


. view business dashboards (across sites). 


3 Potential Usages of YEROTH-ERP- 
3.0 


YEROTH-ERP-3.0 potential usages are: 


1. STOCK AND TRADE EXCHANGES MARKET PLACE 


2. ENTERPRISE RESOURCE AND PLANING SOFTWARE 
for supermarkets and commercial stores 


3. ice. ANY NON GOVERNMENTAL ORGANIZATION, or 
GOVERNMENTAL ORGANIZATION. 


4 Advantages of YEROTH-ERP- 


3.0 


1. YEROTH-ERP-3.0 is 100% stable 


2. YEROTH-ERP-3.0 has an alert system with two types 
of alerts: alerts based on stock—quantity, and time— 
period alerts 


3. users have the choice between small size receipts, and, 
bigger size receipts ("A4”) 


4. YEROTH-ERP-3.0 runs on the Linux operating sys- 
tem, because Linux is stable, performant, and less vul- 
nerable to security breaches in comparison to other op- 
erating systems (Windows 10’) 


5. YEROTH-ERP-3.0 has an user interface "Sales” to 
view sale information (Figure 2), and thus enables 
users to make managerial decisions 


6. YEROTH-ERP-3.0 has an interface "Business dash- 
board” that generates financial accounting reports, 
from sale and payment information, to help managers 
to make "business decisions”. 
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YEROTH-ERP.3.0 - sales - o % 


7.00 € 


1,567,987.00 € 
1,567,287.00 € 


reset 


Figure 2: Sale—information window. 


5 Alert System 


Users with roles « Administrator » or « Business manager » 
are the ones able to create alerts. 


YEROTH-ERP-3.0 allows its users to create two types of 
alerts: 


1. alerts over stocks—quantities 


2. alerts over time intervals (this helps for perissable arti- 
cles and for sales discounts over a period of time). 


5.1 Alerts over Stock—Quantity 


An alert aver a stock—quantity is a message that is sent to 
a pre-determined user whenever “pre-determined” stock— 
quantity (X) of a specific article—stock is reached. 


For instance, Xavier (« Business manager ») could create an 
alert for stock “mango” that will be trigerred whenever stock 
"mango” quantity reaches 100; An alert-message is sent to 
user John (« Storekeeper »). 


5.2 Alerts over Time—Period 


A time-period is defined by a starting—date and an ending- 
date (dates are from the "gregorian” calendar). 


An alert aver a time-period (T) is a message that is gen- 
erated, sent to a pre-determined user, and kept within 
YEROTH-ERP-3.0 from T’s starting—date up to T's ending- 
date. 


For example, an alert with a message has to be sent to Paul 
(« Cashier ») when the date of May 05°" is reached. The alert 
message specifies that a rebate of 20% has to be applied on 
every sale of yoghourt 'trésbon’ during a time interval of 2 
weeks. 


6 Database Management System 


YEROTH-ERP-3.0 uses ’MariaDB’ as the standard DBMS. 
»MariaDB’ is very stable, very performant, and free— 
software. 


Version of - January 12, 2023 - 


30 OF 31 


YEROTH 24 YEROTH-ERP-3.0 Software System Architecture 


Information Brochure of the ERP software system YEROTH-ERP-3.0 YEROTH 2g 


7 Conclusion 


Yeroth-erp-3.0 = Actions ~ adrmarestration window = 


YEROTH-ERP-2.0 - point of sale -LIFO [ pdf receipt size: Wrge (A5)'} 


SYSTEM DAEMON 


em count 
‘Subtotal 
Tax (7.25%) 
Total ATC 


database p addrest: “lacalhoet® - database table “perce 


Laaatitccnanchens Racer Sams cesses sc svanice | Figure 4: Administrative window for business manager. 


higdis 2) Folng-ot=saleyindaw: Figure 4 illustrates the administrative window for business 


Figure 3 illustrates the window for selling articles. managers. 
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YEROTH-ERP-PGI-3.0: 
Configuration MULTI-SITES (SUCCURSALES) 


PROF. DR.—ING. DIPL.—-INF. XAVIER NOUNDOU 


CE LIVRET EXPLICITE COMMENT RE-UTILISER YEROTH-PGI-ERP-3.0 
AVEC DES SITES (SUCCURSALES). 


VERSION : 6 novembre 2023 
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Chapitre 1 


INTRODUCTION 


LE PROGICIEL DE GESTION INTEGRE YEROTH-PGI-3.0 [NOU22, NOU23a, 
NOU23b] permet a ses utilisateurs la réutilisation de la fonctionnalité "multi-sites 
(succursales)"! La fonctionnalité "multi-sites (succursales)" permet a 1 organisation de 
contréler ses activités décentralisées de fagon centralisée a l'aide de YEROTH—PGI-3.0. 
Les opérations des succursales (ou encore d'1 filiale) sont répertoriées dans la base de 
données (MySQL) a l'aide de la colonne ‘localisation’. ’Lacolonne localisation’ de la base 
de données "yeroth_erp_3" CORRESPOND A: 


1. Localisation (INSTALLATION EN FRANCAIS) 
2. Site (EN ANGLAIS) 


dans les interfaces graphiques (GUI) de YEROTH—PGI-ERP-3.0. 
1.1 Définitions 


1.1.1 Filiale (DICTIONNAIRE ROBERT) 


Société jouissant d’une personnalité juridique (a la différence de la succursale) mais 
dirigée ou contrélée par une société mere. 


1.1.2 Succursale (DICTIONNAIRE ROBERT) 


Etablissement qui dépend d’un siége central, tout en jouissant d'une certaine auto- 
nomie. Exemple : Les succursales d’une banque. 
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Chapitre 2 


Configuration D’1 ORDINATEUR D‘1 
SUCCURSALE 


Figure 2.1 — FIGURE ILLUSTRATIVE de la marque succursale 


Yeroth-erp-3.0 ~ Connect a site ~ administration window - x 


Functions Tools Help 
“ad 


Connect a site Company Import Maintenance _ Actions Application parameters SYSTEM DAEMON 


ip address 


connect disconnect 


database ip address; "localhost" - database table: "yeroth_erp_3" - database options: "" 


CHAQUE ORDINATEUR INSTALLE DANS 1 SUCCURSALE posséde 1 identification 
égale a 1 CHAINE DE CARACTERE unique. 


CETTE CHAINE de caractére est la méme pour chaque ordinateur de la succursale 
observée. LA FIGURE 2.1 illustre L’IDENTIFIANT "YEROTH_RD_TEST" d’1 succursale 
de test. Il s’agit de L'ONGLET "Connecter une localisation" dans la fenétre 'FENETRE 
DE L’'ADMINISTRATEUR’! 
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2.1 INSTALLATIONS DE yeroth-erp-pgi-3.0 PAR SUC- 
CURSALE 


1. Chaque copie de YEROTH-—PGI-ERP-3.0 installée sur 1 ordinateur a été compilée 
avec l'identifiant de sa succursale. 


L'IDENTIFIANT de la succursale se fait grace a 1 chaine de caractére dans le fichier 
nommé 


YEROTH_ERP_3_0_CURRENT_LOCALISATION_FOR_RELEASE_BUILD 


CE FICHIER EST A CE MOMENT DANS LE REPERTOIRE de développement : 
yeroth-erp-3-0/yeroth-erp-3-0-development-scripts 
2. AINSI COMPILEE, 1 copie exécutable de YEROTH-—PGI-—ERP-3.0 IDENTIFIE cha- 


cune de ses transactions dans la colonne "localisation" de la base de donnée MySQL 
d'1 IDENTIFIANT EGAL A TOUS LES IDENTIFIANTS de sa succursale. 
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Chapitre 3 


CAS D’1 Filiale 


3.1 TPEet PME 


Figure 3.1 - BASE DE DONNEES CENTRALISEE d’J1 filiale POUR TPE / PME 


ORDINATEUR departement n 
(identifiant "ODn") 


COLONNE "localisation" 


i yeroth_erp_3 OD 


ORDINATEUR departement 2 


OD 
(IDENTIFIANT "OD2") 
Base de OD 
Donnees 
OD 


ORDINATEUR departement 1 [jj 
(IDENTIFIANT "OD1") 


La figure 3.1 correspond a l’'acces a la base de données de LA Filiale (TPE ou PME). 

DES TPE (Tres Petite Entreprise) et des PME (Petite et Moyenne Entreprise) de- 
vraient suivre ce modele avec 1 seul identifiant (pour colonne localisation) pour tous 
leurs ordinateurs (OD1 = OD2 =... = ODn= OD). 
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3.2 Tres Grandes Entreprises (TGE) 


Figure 3.2 - BASE DE DONNEES CENTRALISEE d’1 filiale pour TGE 


ORDINATEUR departement n 
(IDENTIFIANT "ODn") 


Ad COLONNE "localisation" 
r 
yeroth_erp_3 OD1 


ORDINATEUR departement 2 


(IDENTIFIANT "OD2") ODn 
Base de ObD2 

Donnees 
OD4 


ORDINATEUR departement 1 
(identifiant "OD 1") 


aa 
Spa 
aweee 


——Seeesy 
aeesaeeeeety 
Crt 


= 


La figure 3.2 correspond a l’accés a la base de données de LA Filiale TGE. 

DANS DE TRES GRANDES ENTREPRISES (Ex. : santa lucia AHALA, CAMWATER 
BONANSJO, etc.), chaque département de L’ENTREPRISE A SON identifiant (pour co- 
lonne localisation) pour tous les ordinateurs du département (OD1 4 OD2 4... #ODn). 
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Chapitre 4 


CAS D‘1 Succursale 


Figure 4.1 - BASE DE DONNEES décentralisée du SIEGE CENTRAL 


SUCCURSALE n 


(marque "Sn") 


COLONNE "localisation" 


0 ' 
* yeroth_erp_3 Sn 
SUCCURSALE n 
(marque "Sn") Sn 
Base de Sn 
Donnees 
RSALE Sn 


Synchronisation reguliere 


A TEMPS d’intervalles reguliers 


en debian linux) 


SUCCURSALE n 


(marque "Sn") 


Yeroth_erp_3 
Sl 
S2 Base de 
Donnees 
Sn i 


La figure 4.1 correspond a l’accés temps réel et temps differé aux bases de données 
RESPECTIVEMENT locale et centrale de LA SUCCURSALE et dela MAISON MERE (syn- 
chronisés a temps d’intervalles réguliers avec l’outil "RSYNC" DE Debian Linux). 
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4.1 Coupure de connexion Internet 


L'ARCHITECTURE RESEAU PRESENTEE dans la FIGURE 4.1 permet a 1 succursale 
de travailler localement, méme en cas de coupure de connexion internet vers le Siege 
central. 

La synchronisation ultérieure permettrait ainsi de synchroniser des données avec le 
siege central via l’application RSYNC-DEBIAN-LINUX. 
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Chapitre 5 


LOGIN et connexion a 1 succursale 


Seul 1 utilisateur de type (ayant 1 rdle de) "Manager " ("business manager" en An- 
glais) a la possibilité de se connecter a 1 succursale différente de celle ou son ordinateur 
est situé. 


Figure 5.1 — Connexion a 1 succursale (SOCIETE — SITE) 


Activities Applications W yeroth-erp-3-0-standalone-ENGLISH ¥ Tue Mar 28 14:51 F dil G100%~ 


Actions Outils Aide 
ee 


Yeroth-pgi-3.0 - changer d'utilisateur 


Changer d'utilisateur 


nom d'utilisateur 


mot de passe fo] 


annuler 


database ip address: "localhost" - database table: "yeroth_erp_3" - database options: "" 


# ~YEROTH-ERP-3.0 - fenétre de l'uti... 


La figure 5.1 illustre la fenétre dialogue de connexion de YEROTH-—PGI-—ERP-3.0 
pour 1 utilisateur. Cette fenétre contient 1 champs de texte duquel 1 utilisateur ayant 1 
role de Manager peut choisir 1 succursale vers laquelle il peut se connecter. 

Lorsqu’un utilisateur est connecté a 1 autre succursale, toutes des informations et 
données affichées a l’écran proviennent de la base de données de la succursale concer- 
née. 
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Chapitre 6 
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Abstract 


Software correctness properties are essential to maintain quality by continuous and regressive inte- 
gration testing, as well as runtime monitoring the program after customer deployment. This paper 
presents an effective and lightweight ctt program verification framework: YR_DB_RUNTIME_VERIF, 
to check SQL (Structure Query Language) [1] software correctness properties specified as temporal 
safety properties [2]. A temporal safety property specifies what behavior shall not occur, in a soft- 
ware, as sequence of program events. YR_DB_RUNTIME_VERIF allows specification of a SQL temporal 
safety property by means of a state diagram mealy machine [3]. In YR_-DB_RUNTIME_VERIF, a speci- 
fication characterizes effects of program events (via SQL statements) on database table columns by 
means of set interface operations (€, ¢), and, enable to check these characteristics hold or not at 
runtime. Integration testing is achieved for instance by expressing a state diagram that encompasses 
both Graphical User Interface (GUI) states and MySQL [4] databases queries that glue them. For 
example, a simple specification would encompass states between "Department administration’ and 
’Stock listing’ GUI interfaces, and transitions between them by means of MySQL databases oper- 
ations. YR_DB_RUNTIME_VERIF doesn’t generate false warnings; YR_DB_RUNTIME_VERIF specifications 
are not desirable (forbidden) specifications (fail traces). This paper focuses its examples on MySQL 
database specifications, labeled as states diagrams events, for the newly developed and FOSS (Free 
and Open Source Software) Enterprise Resource Planing Software YEROTH-ERP-3.0 [5]. 


Keywords: model-based testing, reactive system analysis, computer software program analysis, computer 
software dynamic program analysis, software integration testing with SQL and GUI, runtime monitoring 


Fig. 1: YR_DB_RUNTIME_VERIF WORKFLOW (diagram inspired from operation diagram in [6]). 


SUT receives user GUI events 
that modify SQL database tables 


STATE DIAGRAM 
SPECIFICATIONS 
as yr_sd_runtime_verif 


C++ code 


SUT + yr—db-runtime-verif 


run conccurrently 


as separate processes 


1 Introduction 


Table 1: YEROTH-ERP-3.0 RELEVANT 
SOFTWARE SYSTEM METRICS 


Software System Metric Value 
User Interface (windows, dialog) number 60 
MariaDB SQL table number 38 
MariaDB SQL table column number 320 
Source lines of code (SLOC) 300, 000 


1.1 Motivations 


This paper describes an effective dynamic analysis 
framework, based on runtime monitors specified 
in Ctt programs (implemented in the software 
library yr_sd_runtime_verif), to perform soft- 
ware temporal safety property checking of GUI 
(Graphical User Interface) based software. 

GUI based software are very comfortable and 
handy to use. However, tools to perform tempo- 
ral safety property verification of GUI software 


corelation 


SUT emits SQL events 
to yr—db-runtime—verif 


PROGRAMS OUTPUT 


DYNAMIC RUNTIME ANALYSIS 
(SUT + yr—db-runtime-verif) 


Ongoing report 
on erroneous SUT 
program state 


and lines of code 


yr—db-runtime—verif 


monitors and analyzes 


SUT SQL events 


are allmost not available as FOSS. The testing of 
combinations between GUI windows and database 
queries that glue them to make sense to the user, is 
allmost unavailable as FOSS, or at all to the best 
of the knowledge of the author of this paper. The 
FOSS Ctt library libfsmtest [7] provides test 
suite generation support for source code behavy- 
ior specifications as mealy automata. However, 
libfsmtest only allows for desirable correctness 
properties, and doesn’t provide GUI (interaction) 
support or as plugin-based. 

Unit or integration testing for GUI widgets is 
available by use of "NUnit" testing frameworks 
like e.g. Qt-Test [8], CppUnit [9], etc.. Software 
testing across GUI widgets (and MySQL queries) 
is however limited in support by these "NUnit" 
framework. To the best of the knowledge of the 
author of this paper, DejaVu [10] provides some 
support for Java’record and replay’ testing while 
FROGLOGIC [11] provides support for Ct+ GUI 
software ‘record and replay’ testing technology. 
Record and replay’ testing means a user performs 
a sequence of events that are recorded by test- 
ing infrastructure and automatically replay later 


on to see if expected events thereof occur. How- 
ever, none of this record and replay’ technology 
tool enable temporal safety property specification 
as FOSS, with SQL as plugin. 

As we will see in the related work, section 7, 
of this paper, most of software correctness prop- 
erty checking frameworks don’t put an emphasis 
on checking temporal safety property of GUI 
software. Characterizing the effects of program 
statements (via SQL statements) on database 
table columns, and to check that these character- 
istics hold or not, is of predominant importance 
for large software systems with an impressive 
number of database tables. Table 1 illustrates 
for instance FOSS YEROTH-ERP-3.0 relevant 
software system metrics. 

It means it can be very difficult for developers 
to keep application related logical requirements 
between the tables without appropriate software 
testing or analysis tools. 

A large amount of former work on runtime 
monitoring assumes for a sequential program, or 
an abstraction of the program as one single source 
code, on which program analysis is performed [12— 
16]. 

The program analysis technique the author of 
this paper presents here abstract SQL events, GUI 
events, or sequences of them, as a state diagram, 
and enables developers to run them sequentially 
against a runtime monitor specified as a Ct* 
program. In particular, the example presented in 
Section 2 specifies results of GUI windows events 
as SQL database pre-conditions on state diagram 
transitions; SQL events are specified as state dia- 
gram transition events. Figure | shows a high level 
overview of YR_DB_RUNTIME_VERIF workflow. 


1.2 Main Contributions 


This paper presents 3 original main contributions: 
ean industrial level quality  frame- 
work (YR_DB_RUNTIME_VERIF: https: 
//github.com/yerothd/yr-db-runtime-verif), 
that solves temporal property _ verifi- 
cation by dynamic program analysis. 
YR_DB_RUNTIME_VERIF makes use of the C** 
Qt-Dbus library, to input a runtime mon- 
itor specification (yr_sd_runtime_verif) 
as Ctt program code, that also enables 
software—library—plugin checks; 


ea Ct library: yr_sd_runtime_verif 
(https://github.com/yerothd/yr_sd_ 
runtime _verif); modeling a state diagram 
runtime monitoring interface using only set 
algebra inclusion operations (€, ¢) for state 
diagram program state specification as pre- 
and post-conditions. 

yr_sd_runtime_verif only enables the 

specification of states diagrams specifica- 
tions as not desirable (forbidden) behav- 
ior specifications (fail traces). Thus, 
YR_DB_RUNTIME_VERIF doesn’t generate any 
false warning. A violation of a safety rule has 
been found whenever a final state could be 
reached. On the other hand, not reaching a 
final state doesn’t mean that there is not a 
test case (or test input) that cannot reach 
this final state. 


e An application of YR_DB_RUNTIME_VERIF to 
check 1 temporal safety property error, found 
in the ERP FOSS YEROTH-ERP-3.0. 


Previous version of this paper 


This paper extends a previous version [17], 
currently in conference proceedings SPLASH-— 
ICTSS 2023 submission, with state diagram with 
more than 2 states, guarded conditions specifica- 
tions, 2 new keywords for state diagram transition 
trace specification ("in_ sql_event_ log”, 
"not in sql event log”), and 
YR_DB_RUNTIME_VERIF binaries with more than 1 
runtime monitor. 


1.3 Overview 


This paper is organized as follows: Section 2 
presents a motivating example that will be used 
throughout this paper to explain the presented 
concepts of this paper. Section 3 presents for- 
mal definitions of the principal concepts used 
in this paper. Section 4 presents the software 
architecture of YR_DB_RUNTIME_VERIF, our GUI 
dynamic analysis framework. Section 5 introduces 
the Ct* software library yr_sd_runtime_verif 
to model states diagrams, and reused by 
YR_DB_RUNTIME_VERIF. We evaluate our dynamic 
runtime analysis in Section 6. Section 7 compares 
this paper with other papers that achieve similar 
work or endeavors. Section 8 concludes this paper. 


Fig. 2: A motivating example, as current bug in YEROTH-ERP-3.0. 
Q0 := NOT_IN_PRE(YR_ASSET, department.department _name). 
Q1 :=IN_POST(YR_ ASSET, stocks.department_ name). 


D [in_set_trace(’DELETE.department.YR_ASSET’, STATE(d))] / ’SELECT.department’ 


Fig. 3: YEROTH-ERP-3.0 administration 
section displaying departments (—Q0). 


administration ~ list - x 


Stockalert  Commandsheet Category buduet ire Bankccount Us 


Department 


1 yeroth departement 1 


2 yeroth departement 2 
3 YR_ASSET 


2 Motivating Example: missing 
department definition 


2.1 The Enterprise Resource 
Planing Software 
YEROTH—ERP-3.0 


YEROTH-ERP-3.0 is a fast, yet very simple 
in terms of usage, installation, and configuration 
Enterprise Resource Planing Software developed 
by Noundou et al. [5] for very small, small, 
medium, and large enterprises. YEROTH-ERP-— 
3.0 is developed using Ctt by means of the Qt 
development library. YEROTH-ERP-3.0 is a 
large software with around 300 000 (three hun- 
dred thousands) of physical source lines of code. 
YR_DB_RUNTIME_VERIF could be used for integration 


Fig. 4: YEROTH-ERP-3.0 
stock asset window listing some 
assets (Q1). 


YEROTH-ERP-3.0 -asset and inventory stock listing ak 


Department | Tota qty Expiration date 


testing of YEROTH-ERP-—3.0, among different 
software modules. 


2.2 Example Temporal Safety 
Property 


The motivating example of this paper con- 
sists of the temporal safety property stipulat- 
ing that "A DEPARTMENT SHALL NOT 
BE DELETED WHENEVER STOCKS 
ASSET STILL EXISTS UNDER THIS 
DEPARTMENT”. This statement means that 
a user shall be denied the removal of depart- 
ment “YR_ASSET’ in Figure 3 because there 
are still a stock asset listed within department 
"YR ASSET’, as illustrated in Figure 4. Figure 2 


Fig. 5: YR_DB_RUNTIME_VERIF command line shell output demonstrating that a final state has been reached 


(Section 6 analyzes these results). 


YR-DB-RUNTIME-VERIF _ console - x 


Actions Tools HELP 


gm 
BAUFRE: 


Enter "source" or "SQL event" for filtering 


SQL Error Event Reporting Logging SQL Event Logging 


[yR-DB-RUNTIME-VERIF] 


06:15:30:204 'SELECT.stocks' yeroth-erp-pgi-3.0 YR-DB-RUNTIME-VERIF 


YEROTH_QVGE_sample_SAFETY_PROPERY_one_Recovery_SAMPLE 


TIME STAMP 


06;:15:33:309 "INSERT INTO categories (id, no 


egorie, nom_departement_produit) values (yr_id, "YR_AS 


SQL recovered executed query 


at’, ‘YR_ASSET} 


YR-DB-RUNTIME-VERIF: this console is registered to the systern d-bus as service: 'yr.db-runtime.verif'. 


illustrates the above temporal safety property as 
a simple state diagram. 


2.2.1 State Diagram Explanation 


’D’ is a start state as illustrated by an arrow end- 
ing on its state shape. ’E’ is a final (error, or 
accepting) state as illustrated by a double circle 
as state shape. 

The pre-condition QO (as a predicate) in state 


’D’: 
"NOT _IN_PRE(YR_ ASSET, depart- 
ment.department name)" means: 

ea _ department named ’YR_ASSET’ 


is not in column ‘department name’ 
of MariaDB SQL _ database table 
‘department’. This might happen whenever 


button ‘Delete’ in Figure 3 is pressed when 
item “"YR_ ASSET?’ is selected. 


Similarly, the post-condition Q1 (as 
a predicate) "IN POST(YR_ ASSET, 
stocks.department name)", in accepting state 
*E’, means: 
e a department named ’YR_ ASSET” is in 
column "department_name”’ of MariaDB 
SQL database table ’stocks’. 


The state diagram event transition in 
Figure 2: ’SELECT.department’ denotes that 
when in ’D’, a SQL ’select’ on database table 
*department”’ has occurred; ’E’ is then reached as 
an accepting state. 


Guarded Condition Expression 


The guarded condition expression 
"Cin_set_trace (’DELETE.department.YR_ASSET’, 
STATE(D))]"means a SQL ’DELETE’ event remov- 
ing a department named ’YR_ ASSET’ from 
MariaDB SQL table ‘department’ must have 
occurred in the trace leading to state ’D’. 


Yr_sd_runtime_verif Specification Code 


The source code specified in Listing 2 also illus- 
trates a specification in Ct* using software library 
yr_sd_runtime_verif of the state diagram spec- 
ification above. 


2.3 YR_DB_RUNTIME_VERIF Analysis Report 


The motivating example automaton in Figure 2 is 
analyzed by YR_DB_RUNTIME_VERIF as follows: 

e whenever department “YR ASSET’ is 
deleted in YEROTH-—ERP-3.0, as done in 
Figure 3, the runtime monitor state ’D’ with 
a state condition QO is entered 


e when MySQL library (plugin) event 
*SELECT. department’ occurs, in Figure 3 
because of YEROTH-ERP-3.0 display- 
ing the remaining product departments, 
the guarded condition for edge event 
*SELECT.department’ is automatically 
evaluated to ‘True’ by Ct library 
yr_sd_runtime_verif, because no other 
guarded condition was specified by the 


developer 

@ yr_sd_runtime_verif enters the 
runtime monitor state to ’E’ and 
state condition Q1 via method 


YR_trigger_an_edge_event (QString 
an_edge_event) because there are still 
assets (yeroth asset 3) left within prod- 
uct department "YR_ ASSET’, as illustrated 
in Figure 4. ’E’ is then an accepting (or final 
or error) state. 


r 


Figure 5 illustrates an analysis result of the 
afore described process, which gets evaluated and 
described in Evaluation Section 6. 


3 Formal Definitions 


yr_sd_runtime_verif’s formal description of 
the state diagram formalism follows Mealy 
machine [3] added with accepting states 
(final or erroneous state), and state dia- 
gram. transition pre- and post-conditions. 
Another excellent, detailed with proofs and 
theory presentation of mealy automata [18] 
is available. In comparison to statechart [19], 
which is a visual formalism for states dia- 
grams, yr_sd_runtime_verif doesn’t support for 
instance the following features: hierarchical states 
(composite state, submachine state), timing con- 
ditions. 


Definition 1. 
A state diagram is a 8-tuple (S,.59,C, 5, A, 6,T,T) 


where: 

e S: a finite set of states 

¢ So € S: a start state (or initial state) 

e® C: a set of predicate conditions; pre- 
conditions are underlined (e.g.: QO), and 
post-conditions are overlined (e.g.: Q1). A 
pre-condition is comparable to a Harel- 
statechart guarded condition. 

e S: an input alphabet, U:= {False, True}. 

‘False’ means no input from SUT into 
YR_DB_RUNTIME_VERIF. 

‘True’ means any input could come from 
SUT. 

e A: an output alphabet (of program events 
en(n € N)), @ the no program event. A 
program event generally corresponds to a 
function or method call at a SUT source code 
statement (or program point). 

e6: 5x C: a 2Qary relation that maps a 
state s to a state-condition c as either a state 
diagram transition pre-condition (c), or as a 
state diagram transition post-condition (@). 

eT:SxXi—> Sx A: a transition function that 
maps an input symbol to an output symbol 
and the next state. 

e :a2—ary relation that maps a state diagram 
transition to a guarded condition expression. 

e T: a set of accepting states; T € S. 


For instance, for the motivating example 
described in Figure 2 we have: 


° S = {D,E}; 
© So =D; 
° C = {Q0, Q1}; 


e > = {False, True}; 
A = {¢,’SELECT.department’}; 
6 = {(D, Q0), (E,Q1)}; 


r= {hr} 


Definition 2. 


A pre-condition of a state diagram transition is a 
predicate that must be true before the transition 
can be triggered. A pre-condition QO could have 
2 forms: _ 
e QO :=IN_PRE(X, Y) that means value "X" 
is in (€) database column value set "Y". 
e QO := NOT_IN_PRE(X, Y) that means 
value "X" is not in (¢) database column 
value set "Y". 


Definition 3. 


A post-condition of a state diagram transition is 
a predicate that must be true after the transition 
was triggered. A post-condition Q1 could have 2 
forms: 
e Q1 := IN_POST(A, B) that means value 
"A" is in (€) database column value set "B". 
¢ Q1 := NOT_IN_POST(A, B) that means 
value "A" is not in (¢) database column value 
set "B". 


For state diagram mealy machines with 
more than 2. states, only the first transi- 
tion has a pre-condition specification (IN_ PRE, 
or NOT_IN_ PRE). Each other transition only 
has a post-condition specification (IN_ POST, 
or NOT_IN_ POST). Since each state only has 
1 outgoing (edge) state transition, the post- 
condition of the previous (incoming) state transi- 
tion acts as the pre-condition of the next transi- 
tion. 


Definition 4. 


A trace T,, =< e°,e!,..,e" > is a sequence of 
SUT events (or SUT program points) e%€{0--"} 
of length n. trace(D) is the trace of SUT events up 
to state D. For instance, for the motivating exam- 
ple described in Figure 2 we have: trace(E) = 
trace(D), < ’SELECT.department’ >. 


T = {((D, False), (D,¢)), ((D, True), (E, ’SELECT.department’))}; 


Proposition 1: NO FALSE 
WARNINGS. 


yr_sd_runtime_verif only allows 1 outgoing 
edge or transition for a state in its specifications, 
and for not desirable (forbidden) behavior, as 
illustrated in Figure 2. There is no need to spec- 
ify the red colored edge in Figure 2 because it 
represents runtime cases where no input events 
arrive from SUT into YR_DB_RUNTIME_VERIF. 
These 2 properties, together with algo- 
rithm *YR_trigger_an_edge_event (QString 
an_edge_event)’ (Listing 3) of 
yr_sd_runtime_verif, ensures that there are 
no false warnings during YR_DB_LRUNTIME_VERIF 
analyses. For example, the runtime monitoring 
or verification systems [12-16] may give false 
warnings. 


3.1 Guarded Condition Expression 
Specification in 
yr_sd_runtime_verif 


Guarded conditions expressions can be _ speci- 
fied using one of the yr_create_monitor_edge 
method and a _ boolean expression of type 
YR_CPP_BOOLEAN_expression. An edge without 
an explicit guarded condition has an implicit 
*[True]’ guarded condition on it. The implicit 
guarded condition ’[True]’ mustn’t be identified 
as an implicit input event ’T’rue’, as specified in 
Definition 1. 

Guarded conditions are meant to be trace 
set specification on program events. For 
instance in Figure 2 (motivating example): 
"[Tin_set_trace (’DELETE.department.YR_ASSET’, 
STATE(D))]"means that a SQL ’DELETE’ event 
removing a department named ’YR_ ASSET’ 
from MariaDB SQL table ‘department’ must have 
occurred in the trace leading to state ’D’, before 
event ’SELECT.department’ can be triggered. A 
guarded condition could have two practical forms: 

e "lin set trace (‘event’, STATE(D))|" is 

equivalent to: ’event’ € trace(D). 


e "Inot in set trace (event’, 


STATE(D))]" is equivalent to: 
’event’ ¢ trace(D). 


where ’event’ is an input event (event € %) 
and ’D’ a state diagram state (D € S). 


Fig. 6: YR_DB_RUNTIME_VERIF: simplified soft- 
ware system architecture. 
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OS system calls t 


4 The Software Architecture 
of YR-DB-RUNTIME-VERIF 


4.1 Dynamic Analysis 


4.1.1 SUT Source Code 
Instrumentation. 


YR_DB_RUNTIME_VERIF runs as a separate Debian 
Linux process from the application to dynami- 
cally analyze (YEROTH-ERP-3.0 in this case). 
Figure 6 illustrates a software system archi- 
tecture layer of a software system that uses 
YR_DB_RUNTIME_VERIF. Figure 6 and Figure 7 illus- 
trate how YEROTH-ERP-3.0 is instrumented 
to send MySQL database events, as they occur on 
due to the GUI of YEROTH-ERP-3.0, to pro- 
cess YR_DB_RUNTIME_VERIF, so it can perform run- 
time analysis of the monitor implemented within 
it. 


4.1.2 Debugging Information. 


Each GUI manipulation of YEROTH-ERP-3.0 
in its instrumented source code part could gener- 
ate a state transition within the analyzed runtime 
monitor state diagram in YR_DB_RUNTIME_VERIF. 
Visualize "line 35" of Figure 5 to observe that a 
specific analysis message is sent to the console of 
YR_DB_RUNTIME_VERIF in cases where a final state 
has been reached; the message at "line 33" is for an 
accepting (final) state of the state diagram spec- 
ification of the motivating example presented in 
Figure 2. 


Fig. 7: YR_DB_RUNTIME_VERIF and 
SUT socket communication (dia- 
gram inspired from Jan Peleska 
diagram—work). 


RIF 


SUT source code emits events as they occur. 


4.2 SQL Events 


YR_DB_RUNTIME_VERIF currently only analyzes the 4 
SQL events in Table 2. 


4.3 A Runtime Monitor (An 
Analysis Client) 


Listing 1: "XML file adaptor for YEROTH— 
ERP-3.0 test cases (reduced from 4 to only 
1 SQL event for paper)." 


| <IDOCTYPE node PUBLIC "—//freedesktop / / 
DTD D—BUS Object Introspection 1.0//EN" 
"http: //www.freedesktop.org/standards/ 
dbus/1.0/introspect.dtd"> 
<node name="/YRruntimeverification" > 
<interface name="com.yeroth.rd. 
TYRruntimeverification" > 
<method name=" 
YR_slot_ refresh SELECT DB MYSQL 
i 

<annotation name="org.qtproject.QtDBus. 
QtTypeName.In0" value="QString"/> 

<annotation name="org.qtproject.QtDBus. 
QtTypeName.In1" value="uint"/> 

<annotation name="org.qtproject.QtDBus. 
QtTypeName.In2" value="bool"/> 

<arg type="QString" direction="in"/> 

<arg type="uint" direction="in"/> 

<arg type="bool" direction="out"/> 

</method> 
</interface> 


</node> i 


An user (an analysis client) of 
YR_DB_RUNTIME_VERIF needs to subclass class 
YR_DB_RUNTIME_VERIF_Monitor. The UML class 
diagram in Figure 8 displays the class structure 


Table 2: SQL Event Dbus Method Interface 


SQL Event Dbus Method Interface 

DELETE YR_slot_ refresh DELETE DB _MYSQL(QString, uint) 
INSERT YR_slot_ refresh INSERT DB_MYSQL(QString, uint) 

UPDATE YR_slot_ refresh UPDATE DB_MYSQL(QString, uint) 
SELECT YR_slot_ refresh SELECT DB MYSQL(QString, uint) 


Fig. 8: YR_DB_RUNTIME_VERIF: simplified class diagram in UML [20]. 


QDBusAbstractAdaptor 


t¥RruntimeverificationAdaptor 


+YR_ slot refresh SELECT DB MYSQL(}: bool 


YR_DBUS COMMON 
+ A RUNTIME MONITOR; YR OB RUNTIME VERIF Monitor 7 
+YR_slot_refresh SELECT DB MYSOL(): bool 


dbusfllente 


YR_DB_RUNTIME_VERIF_Monitor 


+¥R_slot_refresh SELECT DB _MYSQL(): bool 


+00 VERIFY AND or CHECK 1tl_PROPERTY(): bool 
+YR_trigger an edge event(}: bool 


of YR_DB_RUNTIME_VERIF. Qt-Dbus communica- 
tion adaptor IYRruntimeverificationAdaptor 
shall be generated by the user of this library (on 
YR_DB_RUNTIME_VERIF side) using Qt-Dbus com- 
mand qdbusxml2cpp and an XML file, similar to 
the one displayed in Listing 1: 

An analysis client must first override method 


‘DO_VERIFY_AND_or_CHECK_Itl_ PROPERTY’ 


of class ’YR_DB_RUNTIME_VERIF_Monitor’ so 
to implement a checking algorithm for each 
event received from SUT, as for instance the 
events illustrated in Figure 2 of the motivat- 
ing example. The analysis client then calls 
method ’YR_trigger_an_edge_event (QString 
an_edge_event)’ (Listing 3) of class 
*YR_CPP_RUNTIME_MONITOR’ of Ct library 
yr_sd_runtime_verif for each corresponding 
state diagram transition event. 
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Fig. 9: Class diagram in UML [20] to model a 
State Transition Diagram. 


YR_CPP_MONITOR 
_[* ROOT EDGE: YR CPP MONITOR EDGE 

i+ FINAL STATE: YR CPP MONITOR STATE 
+i8_in_SET_ALGEBRA(a_SET VARIABLE:QString, 
a SUPPOSED SET VARIABLE:QString): bool 


1." 


YR_CPP_MONITOR_STATE 


1 


YR_CPP_MONITOR_EDGE 
_————— es 
——_—_—_—————————} 


1 


) 
YR_CPP_MONITOR_EVENT 


YR_CPP_MONITOR_TRACE_EVENT 


1 
YR_CPP_BOOLEAN expression 


Fig. 10: Class diagram in 
UML [20] to model state dia- 
gram transition trace conditions in 
yr_sd_runtime_verif code. 


YR_CPP_BOOLEAN expression 


+evaluate _expression();: bool 


YR_CPP_not_in_SET_TRACE expression 


+evaluate expression(): bool 


YR_CPP _in_SET_ TRACE expression 


——————————————— 
+evaluate expression(): bool 


Listing 2: yr_sd_runtime_verif Ctt code modeling a current bug in YEROTH-ERP-3.0 (Figure 2). 


"departements produits.nom_departement_ produit"); 


: 'YR_CPP_ MONITOR EDGE mega lee et =create_yr_monitor_edge("D", 
3 "select.departements _ produits"); 

5 a_last_edge 0—>get_SOURCE_STATE()—>set_START_STATE(true); 

: a_last_edge 0—>get_ TARGET _STATE()—>set_ FINAL STATE(true); 

9 a_last_edge_0—>set_PRE CONDITION notIN("YR_ASSET", 

ii 

12 |a_last_edge 0—>set_POST CONDITION _IN("YR_ ASSET", 

13 "stocks.nom_departement_ produit"); 

: 


5 yr_sd_runtime_verif: A Ctt 
Library to Model States 
Diagrams 


5.1 Structure Of 
yr_sd_runtime_verif 


yr_sd_runtime_verif is a state diagram 
Ctt library the author of this paper created 
to work with the dynamic analysis program 
YR_DB_RUNTIME_VERIF. Figure 9 and Figure 10 
represent the class structure, in UML, of 
yr_sd_runtime_verif. Listing 2 shows the CTT 
code that models the motivating example in 
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Figure 2, and that uses runtime monitoring Ct* 
state diagram library yr_sd_runtime_verif. 

There is no need to write Ctt code for 
the red specified edge of Figure 2; this rep- 
resents runtime cases where no input event 
arrives from SUT into YR_DB_RUNTIME_VERIF. 

Table 3. specifies which class is in 
yr_sd_runtime_verif code for each runtime 
monitor/state diagram element. 


5.2 Methods for Pre- and 
Post-Condition Specifications 


Table 4 illustrates methods for specifying pre— 
and post-conditions of a runtime monitor 


YR_register_set_final_ state CALLBACK FUNCTION(&YR_CALL_ BACK _final_ state); | 


Table 3: Runtime Monitor Specification Classes 


State Diagram Feature 


Class 


State YR_CPP_MONITOR_ STATE 
Transition YR_CPP_MONITOR_ EDGE 
Event YR_CPP_MONITOR_EVENT 


Trace at state level 


YR_CPP_MONITOR_TRACE_ EVENT 


Guard Condition 


YR_CPP_ BOOLEAN expression 


Set Trace Inclusion at edges 


YR_CPP_in SET TRACE _ expression 


Set Trace non Inclusion at edges 


YR_CPP_not_in SET TRACE_ expression 


Runtime Monitor 


YR_CPP_MONITOR 


Table 4: yr_sd_runtime_verif Methods for Pre-/Post-Condition Specification 


Class YR _CPP_ MONITOR EDGE Methods 


Utility 


set PRE CONDITION _ notIN(QString, QString) 


sets a NOT IN DATABASE pre-condition 


set PRE CONDITION _IN(QString, QString) 


sets an IN DATABASE pre-condition 


set POST CONDITION _ notIN(QString, QString) 


sets a NOT IN DATABASE post-—condition 


set POST CONDITION _IN(QString, QString) 


sets an IN DATABASE pre-condition 


state diagram transition. Each method takes 
in 2 arguments of string (’QString’) type: 
*DB_VARIABLE’, ’db_TABLE__db_COLUMN’. 

The first method argument: ’DB_VARIABLE’, 
specifies which variable is to be expected as 
value for the specification of the second variable 
argument ’db_TABLE__db_COLUMN’. The second 
variable gives in a string to be specified in for- 
mat "DB table _name.DB_table_ column"; and 
its supposed value is the returned value of the first 
variable argument ’DB_VARIABLE’. 


These 4 pre- and _ post-conditions meth- 
ods make assumptions that a program 
variable value ’DB_VARIABLE’ is in set 


"DB_table_name.DB_table_ column" or not; if 
the value of ’DB_VARIABLE’ is in the database 
table column, it means it is in the set (€) of 
values "DB_table_name.DB_table_ column"; 
and not being in the table column means it is 
not in the set (¢). 
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Example from the motivating example in 
Section 2 


Listing 2 of the runtime monitoring specification 
stipulates for instance in its "line 12", as post- 
condition: 
a_last_edge_0-> 
set_POST_CONDITION_INC"YR_ASSET", 
"stocks .nom_departement_produit") ; 
that "YR _ ASSET” shall be a value in the 
value set (€) of SQL table ’stocks’ column 
*nom_ departement produit’. 


5.3 SUT Event Processing Method 
YR_trigger_an_edge_event 


Listing 3 illustrates the pseudo-code of 
yr_sd_runtime_verif SUT event processing 
method YR_trigger_an_edge_event (QString 
an_edge_event). ’YR_trigger_an_edge_event (QString 
an_edge_event)’ is responsible for interpreting 
a monitor at runtime, based on its current state, 
and on the current event received from SUT. Each 
state in yr_sd_runtime_verif states diagrams 


Listing 3: Ct*  Pseudo-code for YR_trigger_an_edge_event(QString an_edge_event): 
yr_sd_runtime_verif method for triggering state diagram events (edges or transitions). 


shall have only 1 outgoing edge (transition), by 
specification and construction, as explained in 
Proposition 3 in Section 3. 

The algorithm in Listing 3 demonstrates 
that, given correct trace and event information 
from SUT, yr_sd_runtime_verif always exactly 
matches the user specification. Thus never giving 
false warnings. 
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Table 5: SUT (YEROTH-ERP-3.0) Trace Output (Figure 5). 


CONSOLE OUTPUT LINE SQL EVENT 


SUT PROGRAM POINT (TRACE) 


21 "DELETE.department.YR_ASSET" | "src/admin/lister /yeroth-erp-admin-lister-window.cpp:1603" 
22 "DELETE.merchandise.YR_ ASSET" | "src/admin/lister /yeroth-erp-admin-lister-window.cpp:1626" 
23 "SELECT.department" "src/yeroth-erp-windows.cpp:967" 


6 Evaluation 


The main experimental results in this paper 
demonstrate the efficacy of our tool to find errors 
in the SUT (YEROTH-ERP-3.0), presented in 
Subsection 2.2. 


Qualitative Results. 


SUT (YEROTH-ERP-3.0) TRACING. 


Table 5 illustrates SUT source code trace informa- 
tion as presented in YR_DB_RUNTIME_VERIF console 
output in Figure 5. We have translated from 
French to English the MariaDB SQL table names. 


SQL EVENT CALL SEQUENCE. 


A careful observation of the output in Figure 
illustrates the following sequence: 
e line 23: at state D, execution of the state 
diagram event "’SELECT.department’ " (SUT 
button ‘Delete’ has been pressed at line 21) 


5 


select * from departements_produits WHERE 


line 28, line 29: evaluation of the pre— 
condition QO of state D stating that prod- 
uct department "YR ASSET” is not exis- 
tent evaluates to TRUE’ (triggering of event 
"DELETE.department.YR_ASSET’ " by press- 
ing of SUT button ‘Delete’ at line 21 
has removed any asset department name 
"YR _ ASSET’). 


nom_departement_produit 


Runtime Performance. 


YR_DB_RUNTIME_VERIF and yr_sd_runtime_verif 
don’t incur a runtime supplemental overhead 
to the SUT, apart from emitting SQL events 
from SUT to YR_DB_RUNTIME_VERIF as they 
occur, since no hand-shaking mechanism is 
used between YR_DB_RUNTIME_VERIF and the SUT. 
The emission of an SQL event from SUT to 
YR_DB_RUNTIME_VERIF doesn’t cost more than 2 
statements execution time (getting a pointer 
to the DBUS server, and calling a method 
*°YR_slot_refresh_SELECT_DB_MYSQL’ or other 
similar 3 methods (for INSERT, UPDATE, and, 
DELETE) on it). 


*YR_ASSET’ ; 


* [YR_CPP_MONITOR: : CHECK_PRE_CONDITION_notIN:] precondition_IS_TRUE: True 


line 31, line 32: checking post—condition 
Q1 in state E (there are still stocks in 
stock department "YR ASSET’) evaluates 
to "TRUE’, thus state F is reached as an 
accepting state, because department name 
"YR_ ASSET” still exists in SUT SQL table 
"stocks", as illustrated in Figure 4 of the 


motivating example: 
"execQuery: select 


* from stocks WHERE nom_departement_produit 


"YR_ASSET’ ;" 


*[YR_CPP_MONITOR: :CHECK_post_condition_IN:] postcondition_IS_TRUE: True 
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7 Related Work 
e SUT 


source code _ instrumentation 
with runtime monitor specification. 
"Clara" [12] enables to express software 
correctness properties using AspectJ and 
dependency state machines, both as instances 
of the typestate formalism, a formalism that 
is merely used for checking correctness of 
programs by a static compilation (analysis) 
technique called typestate checking. The 
Clara framework weaves (instruments), and 
annotates a program with runtime moni- 
tors using AspectJ, then tries to optimize 
the weaved program by static analysis. The 
"residual program”, meaning the weaved 
statically optimized program is then exe- 
cuted and runtime monitored by developers 
to detect runtime errors. Runtime monitor- 
ing tools [13-16] work as similar as the Clara 
framework does. 

YR_DB_RUNTIME_VERIF doesn’t instrument 
the System Under Test (SUT) with any 
specification. It runs the runtime monitor 
concurrently from the analyzed SUT, but 
not with hand-shaking mechanism, thus not 
increasing runtime execution of the SUT. 
YR_DB_RUNTIME_VERIF specifies the runtime 
monitor as a state diagram mealy machine, 
a subset of typestate, specified as a CTT 
program, and extended with accepting states 
and state transition pre- and post-condition. 


SUT binary code instrumentation with 
a runtime monitor. With tracerory [6, 
21|", Jon Eyolfson and Patrick Lam 
use runtime program binary code instru- 
mentation technique in INTEL-pin [22] to 
instrument running programs for purposes 
of detecting unread memory. I.e., tracerory 
doesn’t generate itself a runtime monitor, 
it uses INTEL-pin [22] to generate a run- 
time monitor for its verification purposes. 
"Purify" [23] doesn’t allow for SUT user cor- 
rectness property specification. It has built-in 
memory access safety properties to check 
offline on program execution, after instru- 
mentation of the SUT, its third-party, and 
vendor object-code libraries. 

In contrast, with YR_DB_RUNTIME_VERIF, 
the user instruments the source code 
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of the analyzed Ctt program at com- 
pile time with SQL events emitting code. 
YR_DB_RUNTIME_VERIF monitors program trace 
events at database level, and not at pro- 
gram counter level as tracerory does. 
YR_DB_RUNTIME_VERIF inputs a SUT correct- 
ness property specification as a state diagram 
(as a subset of LTL [2]). 


Specification as set interface opera- 
tions. "Hob" [24, 25] is a program verifi- 
cation framework that enables to: charac- 
terize effects of program statement on data 
structures by means of all (V, 4, etc.) alge- 
bra abstract set interface operations; and to 
check that these characteristics hold or not, 
using static analyses. 

YR_DB_RUNTIME_VERIF is a program verifi- 
cation framework that enables to: character- 
ize effects of program statements (via SQL [4] 
(Structure Query Language) on database 
table columns by means of set interface oper- 
ations (€, ¢); and to check that these charac- 
teristics hold or not, using dynamic runtime 
analysis. 


Concurrent Event Stream Analysis. 

"DejaVu " [26] enables to check safety 
temporal property expressed in first-order 
past linear-time temporal logic (FO- 
PLTL) for events that carry data. DejaVu 
inputs a trace log (offline) and a FO- 
PLTL formula, and outputs a boolean value 
for each position in the inputted trace. 
"LocScope" [27] checks, offline, software 
systems correctness properties expressed 
using a rule-based specification language 
over state machines. It is not very precise 
what type of state machine is created and 
processed. "LOGSCOPE" translates specifica- 
tions into Ctt monitors (that could carry 
data). "EventRaceCommander" [28] repairs in 
web applications (online), event race errors, 
a kind of safety error. 

States diagrams specifications are 
implemented as Ct* program monitors 
using Ct library yr_sd_runtime_verif. 
YR_DB_RUNTIME_VERIF outputs a developer 
given (by means of a callback function, as 


seen in ’line 15’ in Listing 2) string mes- 
sage | in case an accepting state was entered, 
and a trace event of YEROTH-ERP-— 
3.0 leading to it. YR_DB_RUNTIME_VERIF’s 
monitors need not store data, as DejaVu 
monitors must. YR_DB_RUNTIME_VERIF events 
also carry data (database table and column 
name, records quantity modified by current 
SUT event). Runtime monitors could be 
checked against programs written in any 
programming language or framework, as 
long as they emit necessary SQL events to 
YR_DB_RUNTIME_VERIF. 


‘'yYR_ DB RUNTIME _VERIF_Monitor_notify SUCCESS _ VERIFICATION’ 


in this paper motivating example in Figure 5. 
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Fig. 11: A Mealy Machine State Diagram Specified Using yr_sd_runtime_verif Specification 


Language. 


1. yr_sd_mealy_automaton_spec yr_missing_department 


cf 


ou PWN 


START_STATE(d) :NOT_IN_PRE(YR_ASSET , department . department_name) 
->[{in_sql_event_log(’ DELETE. departement .YR_ASSET’ , STATE(d))]/’ SELECT .department’ -> 
ERROR_STATE(e) : IN_POST(YR_ASSET, stocks. department_name) . 


Fig. 12: ’YR_QVGE’ model for the example specification in Figure 11. 


FINAL_STATE_AUTO(E): 
IN_POST(YR_ASSET_cat, 
stocks.categorie): 
recovery_sql_query(categories, INSERT INTO cat 
values (yr_id, YR_ASSET_cat’, YR ASSET )’). 


NOT_IN_PRE(Y 


START_STATE(YR); 
/ ASSET_cat, 


ies (id, nom_categorie, nom_departement_produit) 


[in_set_trace("DELETE.categories.YR_ASSET _cat’, STATE(YR))] / ‘SELECT.stocks’ 


iés.nom_categorie) 


8 Conclusion And Future 
Work 


This paper has presented a lightweight CTT 
Qt-Dbus [29] tool to check a program against a 
runtime monitor using set interface operations (€ 
, €) on program statement: YR_DB_RUNTIME_VERIF. 
YR_DB_RUNTIME_VERIF doesn’t generate false warn- 
ings; YR_DB_RUNTIME_VERIF specifications are not 
desirable (forbidden) specifications (fail traces). 
Since the concurrent communication between 
YR_DB_RUNTIME_VERIF and a program occurs over 
the RPC (Remote Procedure Call) instance Dbus, 
a runtime monitor could be checked against pro- 
grams written in any programming language or 
framework, as long as they emit the necessary SQL 
events to YR_DB_RUNTIME_VERIF. 
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Future work would be a tool-chain to validate 
yr_sd_runtime_verif models as represented in 
this paper. 

Also, the author of this paper has devel- 
oped a graphical drawing tool (YR_QVGE) for in 
Section 3 defined state diagrams. A model of 
YR_QVGE is shown in Figure 12. It is an extension 
of the FOSS (Free and Open Source Software) Qt 
Graphviz [30] drawing tool QVGE [31]. YR_QVGE 
generates, from a model, an input file for the 
compiler yr_sd_runtime_verif_lang_comp. 
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Listing 4: ’DO_ VERIFY AND _or_CHECK_ It] PROPERTY’: YR_DB_RUNTIME_VERIF’s overridden 
method for processing SUT event stream Ct* pseudo-code. 


1 [bool DO_ VERIFY _AND_ or CHECK _ ltl PROPERTY( 


2 QString sql_table NAME, | 
3 SQL_CONSTANT_ IDENTIFIER cur_SQL_ command) | 
4|{ | 
5 switch (cur_SQL_ command) | 
6 
il case SELECT: 
8 
9 if ("department" == sql_table NAME)) | 
10 | 
11 return YR_trigger_an_edge_event("’select.department’"); | 
12 } 
13 break; 
14 
15 default: 
16 break; 
17 } 
18 
19 return false; 
20 |} i 
A Processing of SUT Event B YR SD RUNTIME VERIF 
Stream By An Analysis SPECIFICATION 
Client LANGUAGE 
Listing 4 illustrates the pseudo- 
code of YR_DB_RUNTIME_VERIF 
SUT event processing method 


‘DO_VERIFY_ AND or CHECK _Itl PROPERTY’. 
An analysis client must first override method 
‘DO_VERIFY_AND_ or CHECK _Itl PROPERTY’ 
of class "YR_DB_RUNTIME_VERIF_Monitor’ so to 
implement a checking algorithm for each event 
received from SUT, as for instance the events 
illustrated in Figure 2 of the motivating example. 

The analysis client then calls method 
*YR_trigger_an_edge_event (QString 
an_edge_event)’ of class 
*YR_CPP_RUNTIME_MONITOR’ of Ct library 
yr_sd_runtime_verif for each corresponding 
state diagram transition event. 
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Fig. 13: Grammar in Backus-Naur Form (BNF) of yr_sd_runtime_verif Mealy Machine 
State Diagram Specification Language. 


(specification) ::= yr_sd_mealy_automaton_ spec ’{’ (mealy-automaton-spec) ’.’ ’}’ 


(mealy-automaton-spec) ::= (sut-state-spec) 
|  (sut-state-spec) ’—’ (sut-edge-state-spec) 


sut-edge-state-spec) ::= (sut-edge-mealy-automaton-spec) ’—’ (mealy-automaton-spec) 


sut-edge-mealy-automaton-spec) ::= (edge-mealy-automaton-guard-cond) (event-call) 


( 

( 

(edge-mealy-automaton-guard-cond) ::= /* empty */’/’ | ’[ (trace-specification) ’|’’/’ 
(trace-specification) ::= (in-sql-event-log) | (not-in-sql-event-log) | (in-set-trace) | (not-in-set-trace) 
( 


sut-state-spec) ::= (start-state-property-spec) 

|  (start-state-property-spec) °:’ (algebra-set-specification) 
|  (state-property-spec) ’:’ (algebra-set-specification) 
|  (final-state-property-spec) °:’ (algebra-set-specification) 


? (algebra-set-specification) i 


| (final-state-auto-property-spec) 
(recovery-sql-query-spec) 
algebra-set-specification) ::= (in-algebra-set-spec) | (not-in-algebra-set-spec) 
in-algebra-set-spec) ::= (in-spec) ’(’ (prog-variable) ’,’ (db-table) ’.’ (db-column) ’)’ 
not-in-algebra-set-spec) ::= (not-in-spec) ’(’ (prog-variable) ’, (db-table) ’.’ (db-column) ’)’ 
in-sql-event-log) ::= in_sql_event_log’(’ (event-call) ’,’ (state-property-specification) ’)’ 


not-in-sql-event-log) ::= not_in_sql_event_log’(’ (event-call) ’,’ (state-property-specification) ’)’ 


e 2 


, (state-property-specification) ’)’ 


in-set-trace) ::= in_set_trace’(’ (event-call) 
not-in-set-trace) ::= not _in_set_trace’(’ (event-call) ’,’ (state-property-specification) ’)’ 


( 
( 
( 
( 
( 
( 
( 
( 


in-spec) := IN _ BEFORE | IN AFTER 
| IN PRE|IN POST 


(not-in-spec) := NOT_IN BEFORE |NOT_IN_ AFTER 
| NOT IN PRE|NOT_IN_ POST 


(start-state-property-spec) := START _STATE’(’ AlphaNum ’)’ 
(state-property-spec) ::= STATE’(’ AlphaNum ’)’ 


(final-state-property-spec) := END _STATE’(’ AlphaNum ’)’ 
| FINAL STATE’(’ AlphaNum ’)’ 
| ERROR STATE’(’ AlphaNum ’)’ 


(final-state-auto-property-spec) := END STATE AUTO’(’ AlphaNum ’)’ 
| FINAL STATE AUTO’(’ AlphaNum ’)’ 
| ERROR STATE AUTO’(’ AlphaNum ’)’ 


(recovery-sql-query-spec) ::= recovery sql _query’(’ (db-table) ’,’ (sql-recovery-query) ’)’ 
(sql-recovery-query) ::= String 

(event-call) ::= String 

(prog-variable) ::= AlphaNum 

(db-table) ::= AlphaNum 19 

( 


db-column) ::= AlphaNum 


Fig. 14: YEROTH-ERP-3.0 Maintenance Verification Interface. 


Yeroth-erp-3.0 ~ Maintenance ~ administration window - x 


Functions Tools Help 


iad E- @ Main menu 


Connect a site Company Import Maintenance Actions Application parameters SYSTEM DAEMON 
Runtime VERIFICATION DATABASE 


00:40:17:995 SELECT.clients ERP_PGI_ runtime_verif 
00:40:18:043 SELECT.charges_financieres ERP_PGI_ runtime_verif 
00:40:18:164 SELECT.achats ERP_PGI_ runtime_verif 
00:40:18:202 SELECT.marchandises ERP_PGI runtime_verif 
00:40:18:227 SELECT.comptes_doperations_comptables ERP_PGI runtime_verif 


00:40:18:261 SELECT.courriers_alertes ERP_PGI_ runtime_verif 


refresh status 


database ip address: "localhost" - database table: "yeroth_erp_3" - database options: "" 


C YEROTH-ERP-3.0 
MAINTENANCE 
VERIFICATION 
INTERFACE 
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